John Philip
Just Member
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 ??
'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 ??
