Subject: Re: [netatalk-admins] papd problem - never closes
From: Les Klein (les@psgroup.cix.co.uk)
Date: Thu May 28 1998 - 12:56:50 EDT
Dear Wesley
Thanks for taking the time to reply to my comments.
>
> > 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.
>
OK, here is the most convincing reason to do so (in my humble opinion):-
There are a number of Mac applications, most notably Quark Xpress, FreeHand,
PageMaker, et al. that allow a user to embed EPS files in their documents.
Since these applications are not able to parse EPS files they send them as
is to the LW driver.
Because EPS files are already PostScript the LW driver does not modify them
in any way so if the EPS file contains binary data then that's what will get
through to papd (and this is what has happened to me).
(It is actually worse than this since QX and some other applications don't
even use the LW to generate their PostScript!).
I'm curious to know why the papd man page specifically warns about all 8
bits being accepted if binary data isn't?
> > 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.
>
That's OK so why can't papd do this (look for %%Begin Binary)?
> So, the problem is probably with your printer driver.
>
Maybe so, but there are plenty of old pre-DSC applications out there
especially ones that don't run on Mac's. The file with the trailing EOT
comes from a PC and all Windows PostScript files have EOT as their last
character.
Regards
Les Klein.
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:32:45 EST