The wonderful world of IP printing ;-(

[John Philip]

Have been working on an interesting problem with IP print as described below.
'Funny' enough I have yet to hear from the 'eggheads' at Apple (locally as well as Cupertino) regarding this problem.
Elswhere on MacOSX forum, I have described the problems in OSX - and their solution - but here's the OS9.x version - and it seems to have no apparent solution:
--
First a cut from my error report:
--
Customer is a large nationwide newspaper.

Problem setup:
The daily paper is produced on a mainly Apple Computer based network.
Almost all the production DTP computers are Apple.
They print via 100Mbit network to either HP Deskjet or Lexmark printboxes -
and from there directly to the printers.
Printers are mainly HP and Lexmark.

Print:
- Some files print OK.
- Some files print partly OK. I.e. The first part of a doc is Ok, then
comes
'assorted' PostScript errors 1) and then the rest of the print is a (long)
sequence of pages with one or two lines of garbled text/numbers and nothing
else.
- Some files only print the garbled text as described above.

The customer have not been able to find a 'behaviour pattern' in the
errors.
He has noted that AppleTalk usually prints fine.
The customer is currently trying out an Xserve to see if spooling through
that would remedy the problem. At this point however it does not seem to
have any effect on the problem.

Description:
There are two main encodings for binary print:
Standard Protocol (SP)
and
Tagged Binary Core Protocol (TBCP)
The two protocols are incompatible and none is an offspring of the other.

AppleTalk's Printer Acces Protocol (PAP) can transmit TBCP - BUT - this is
very rarely the case..
As a rule binary data is transmitted via PAP in SP coding.
A lot of printing units (and print boxes) assumes that binary data
transmitted via PAP is in SP coding.
Therefore Appletalk printing usually works fine.

PC networking protocols as DLC, LBR (and print originating from an LPT
port)
prefers to send data as (ASCII) text.
Binary data are transmitted in TBCP coding.
A lot of printing units (and print boxes) assumes that binary data
transmitted via DLC, LBR (or form an LPT port) are in TBCP coding.

HP printing equipment behaves as described above - and can (according to
HP)
NOT be modified to assume that data are recieved in any other way.
Technotes and 'talk-on-the-internet' indicates that Lexmark equipment
behaves the same way - and is equally unmodifiable.

Microsoft recommends that one:
a) uses AppleTalk to print these jobs
and
b) Ensures that all data sent, are encoded as ASCII text.

a) is not an option as the customer wishes to terminate AppleTalk on
their network.
b) could be a solution, providing the customer firmly implements
ASCII
data transmission.

PS.: The 'Good ol' ASIP 6.x' had a 'button' enabling printspoolerjobs to be
converted to text. This function worked rather well then. Unfortunately OSX
does not seem to have an option like this implemented.

Ad 1) The PostScript errors all indicate a problem with a picture.
Presumably The doc prints ok, but the 'runs into' a pic saved as binary
data
from photoshop. As the binary data is in the wrong encoding from the
printers expectations - 'the chain falls off' at this point.

--
End of error report
--
After this I have been testing things out at the customer's installation - and am now 99,9% sure that the problem is as described above.
Unfortunately the customer cannot 'control' his many users, neither has he possibility to control digital material (Photos) received from third party/-ies.
As it is a mayor newspaper, a lot of the picture material comes from 'outside'/Third party sources.

I have heard rumors of an ancient application, called something like: 'LPRprint' or' MacLPR' an application that should be able to convert ASCII to binary and vice versa on-the-fly - unfortunately I have not been able to find this (or related) applications.
--
Any good ideas out there ??

[sixthring]

I was having a similar issue printing to a HP LaserJet 8150 when there were incompatible graphics data in the job. To rectify this I created a the IP printer using a queue of BINPS for Binary PostScript.

[roger]

I had a similar problem when I setup an IP printer and didn't quite get the right drivers. I can't remember the exact model of printer I was using (about 4 years ago now) but say I was using the 1234-L I only installed the drivers for 1234-M (you get the idea).

Anyway, mostly it was fine, but occaisionally the conversion to postscript when a little screwy on more exotic content (like graphics) and it went wrong just like you describe - it part printed documents and streaming pages with a couple of characters on them.

A quick change of drivers sorted it out. I doubt if you will have an easy solution to your problem, but somewhere along the line the print language is not being generated properly.

R.

[John Philip]

Originally posted by sixthring
I was having a similar issue printing to a HP LaserJet 8150 when there were incompatible graphics data in the job. To rectify this I created a the IP printer using a queue of BINPS for Binary PostScript.

Could you give me a 'manual' as how to do this? or refer me to a www-adress where I can find more about it ?

Thanx

[John Philip]

Originally posted by roger
I had a similar problem when I setup an IP printer and didn't quite get the right drivers. I can't remember the exact model of printer I was using (about 4 years ago now) but say I was using the 1234-L I only installed the drivers for 1234-M (you get the idea).

Anyway, mostly it was fine, but occaisionally the conversion to postscript when a little screwy on more exotic content (like graphics) and it went wrong just like you describe - it part printed documents and streaming pages with a couple of characters on them.

A quick change of drivers sorted it out. I doubt if you will have an easy solution to your problem, but somewhere along the line the print language is not being generated properly.

R.

I quite get the picture.
Just a comment to your last sentence:
I have gone 'into' the transferred data, and actually established that the 'Protocol problem' is as I stated in my first post.
=
Problem only occurs with binary data.
Apple sends IP print in SP format
PC's send IP print in TBCP format
Printer assumes that all binary data originating from an LPT port is in TBCP format.
Upon receiving data in SP format it garbles as described.
Will try to 'fiddle' around with the drivers as it sounds like a good bet - maybe one or more of HP/Lexmark's drivers can generate binary data in the right protocol format...
Crossing fingers and toes and will get back with more info shortly

Thanx

[sixthring]

Here is a screen shot of what I did when creating an IP printer.

[John Philip]

..and simple :-D

will try ASAP

thanx again

John Philip

[sixthring]

Did my post help with your issue?