Subject: Re: [netatalk-admins] papd problem - never closes

From: Les Klein <[email-masked]>
Date: Thu, 28 May 1998 17:56:50 +0100

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.

---

From: Andras Kadinger <[email-masked]>
Date: Fri, 29 May 1998 00:21:07 +0200

Les, Wesley,

Les Klein wrote:
> Wesley Craig wrote:

Well, with the routines I sent to You this problem can easily be
overcome, and You can get fully transparent binary stream handling,
while retaining the 'line-orientedness' needed for DSC comment handling.

The %%BeginBinary (or, as the more recent DSC 3.0 suggests, %%BeginData,
but apparently noone really uses that) convention might really be a win
if You process large amounts of binary PostScript data; unfortunately,
there are existing implementations blindly spitting out '%%BeginBinary:
1' regardless of the actual amount of data as well as outputting Type1
font definitions in binary (they should be ASCII unless the environment
is 'well-controlled'). These issues seem to indicate that full binary
transparency is easier to do, than trying to parse and trust comments.

The approach I found to be the best was to take the
%%BeginBinary/%%BeginData comment as a hint to speed up processing, and
then just to prevent things from breaking, read up to the next
%%EndBinary/%%EndData - although this measure becomes unnecessary when
being really binary-transparent. The worst case in this scenario would
be misinterpreting some reasonably comment-like sequences in the binary
data.

As of broken drivers: unfortunately, the newest generation of LW drivers
seem to provide an 'ascii/binary PostScript' option...

Les, You seem to be working in the DTP area just as me. I would gladly
cooperate.

Wesley, look, here comes the first of the projects! :-)

Sincerely,
Andras Kadinger
[email-masked]