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 10:37:56 -0700
At 11:47 AM +0100 10/8/03, David Burgun wrote:
Yes, it's using PAP.
I really don't know that much about OT and I've just started on this
project so it's all quite new to me, it's just that I'm the only Mac
engineer here and am important customer has reported this bug.
The App is running on OS 9, on OS X we just use a standard app
(iPhoto, Photoshop etc) to print to the "printer". The Application
is MacOS 9 only at present (we are in the process of carbonizing it
now) and it has been installed on the MacOS 9 side. I'm guessing
that the printer drivers that are installed are picking up the print
request which then converts the data to a PDF and sends it to the
"Printer".
It all works fine except that I don't get the T_MORE bit set to 0.
Also from the code, I have found this comment:
// the proper way to detect the end of a file is to look for
// the EOF flag at the end of the file.
// It also appears that looking for the T_MORE flag to be clear
// is not a reliable way to detect the end of a file.
// When a status request is sent by the client that is sending
// data, the T_MORE flag appears to be cleared for the incoming
// packet.
//???Don - This needs doing but doesn't seem to cause a problem
So it looks like someone thought about this in the past.
If I manually force the bit to 0 in the debugger, the file gets processed ok.
Thanks for your time, All the Best
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,
--
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.