Re: AppleTalk/OpenTransport MacOS X Problem
Re: AppleTalk/OpenTransport MacOS X Problem
- Subject: Re: AppleTalk/OpenTransport MacOS X Problem
- From: Rich Kubota <email@hidden>
- Date: Wed, 8 Oct 2003 12:22:04 -0700
At 6:59 PM +0100 10/8/03, David Burgun wrote:
David,
While I haven't investigated this myself, it would help to see if
the last packet of the print job sent by the client, has the EOF
bit set. When the EOF bit is set, OT clears the T_MORE flag, when
this option is enabled. I suspect that the client is not setting
the EOF bit of the last PAP packet.
It could be that this is the design of the client so that it can
handle multiple jobs - a PAP printer has to parse the packet
contents to see the EOF flag to know where the end of the job is.
Another job could be piggy-backed over the same connection, rather
than having the client close the existing transaction and reopening
a new one.
As for carbonizing the PAP product, it should work under Classic
and OS9, however, it will not work under OS X. There is no PAP
support within the Open Transport framework for OS X. for X, you
will need to use AppleTalk BSD API instead,
Thanks for this. The problem is I am not sure exactly how the whole
thing hangs together.
I run the "Printer" App on MacOS 9.
The App is also installed on the MacOS 9 Partition of the X Machine.
I used the PrintCenter Utility and configured the"Printer" using a
PPD that was installed with the App. I the launch iPhoto and open an
image and print it.
This is the same action in 9 and X except that I use PhotoShop under 9.
I don't see how I could get to the data on the client to be able to
set the EOF bit, since it's a third party app that is actually doing
the printing.
I was thinking of the use of Etherpeek on a third Macintosh system,
or the use of a different hardware or software sniffer to watch
packet traffic with.
Unless there is a driver installed with the App (running under
Classic) that gets control that handles moving the print data over
the network.
I have a work-around for now. The files are all in PDF format and
end in "%%EOF" so I scan the last 5 characters of each packet
instead of checking the T_MORE flag. This is just a temporary fix
until I can figure out what is happening.
You might also want to check whether you are catching the beginning
of the "%%EOF" string sequence in the last 4 bytes of the packet, as
the remaining byte may be in the next packet that is read.
--
Sincerely,
Rich Kubota
email@hidden
(408) 974-6212
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.