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

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

Dear Robert
>
> Greetings again,
> 
> Sorry, I didn't read too carefully ...
> 
> > ..... Also, papd never closes PAP properly if the very
> > last character in a PostScript file is Ctrl-D ('\004'). Looking at the
> > source code for 1.4b2 it looks like netatalk/papd can not work with
binary
> > files. It does however look quite easy to correct. Can anyone
confirm/deny
> > this or say if they have already modified the code before I have a go?
> > Thanks
> > 
> > Les Klein.
> 
> With the source code for netatalk 1.4b2 comes the man pages for papd.
> It describes the problem you mention and how to call/start pap so
> it can work arround these problems.
> 
Thanks for the reply but my man pages do not mention this problem at all.
The man page states that papd accepts a full 8 bits and that the printer
needs to be configured for this. (If you like I will send you my copy of
papd.8 from the 1.4b2 sources).
Well, my printer is configured for that and it prints binary PostScript
files OK.
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.
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.

Regards

Les.

---

From: [email-masked]
Date: Thu, 28 May 1998 10:32:04 -0400

> From:    Les Klein <[email-masked]>
> To:      "robert o'kane" <[email-masked]>

> will find "*stop = '\n'". I.e. it blindly overwrites a \r with a \n and

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.

> 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