Subject: Re: [netatalk-admins] papd problem - never closes
From: wesley.craig@umich.edu
Date: Thu May 28 1998 - 10:32:04 EDT
> From: Les Klein <les@psgroup.cix.co.uk>
> To: "robert o'kane" <okane@em.uni-frankfurt.de>
> The problem is with papd. Specifically the markline() function exits when
> either a \r or a \n is found but then in magics.c, lp.c and header.c you
> will find "*stop = '\n'". I.e. it blindly overwrites a \r with a \n and
> corrupts binary data.
headers.c, magics.c, and queries.c, not lp.c. Changing the end of line
character to \n will in fact corrupt binary jobs, presuming that you
are sending binary jobs to papd. I'm not sure why you would be, since
it answers the question "do you support binary input" with "no". It
would be fairly simple to add binary support, but to date I haven't
heard any convincing reason for me to do so, and no one's provided
patches.
> It seems to me that markline() is also the reason that papd fails if the
> very last character sent is a '\004'. This is because markline() is still
> looking for a \r or \n and one never comes.
This is a short-coming in papd. I have a work-around (implemented to
work around bugs in Desktop printing), but it "corrupts" the input as
above. I say "corrupts", because your input stream is clearly already
corrupted if you have a dangling '\004'. What driver are you using
that thinks it ought to send an EOT character on a PAP stream? That's
clearly way out of spec. PAP is expecting PostScript Document
Structure Convention compliant files. DSC is pretty much line
oriented, and pretty much states that the end-of-line character isn't
important. Unless you're supporting binary, which papd doesn't. If it
did, it would still only be supported inside DSC comments that
indicated the binary section.
So, the problem is probably with your printer driver.
:wes
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:32:46 EST