Possible Enhancement:
In 'PrinterSetupWizardSheet.cpp', method
CPrinterSetupWizardSheet::InstallPrinterPDLAndLPR(), around line 431 in the
107_1 release, if you insert the following line in the code...
portData.dwDoubleSpool = 1;
All LPR printers created by the Bonjour Print wizard will automatically
be built with the goofy 'LPR Byte Counting Enabled' checkbox enabled. Any
printer created in this manner will ALWAYS be successfully printed to.
Add checkbox for this in the UI of the Windows Bonjour Print Wizard and
key off it when you build the printer and you will be one step closer to
hassle-free printer setup.
=====
What I think this means (LPR gurus I am sure know more, so take the
following with a grain of salt)
We are adding Bonjour support on the windows side to our product
Built a printer but it failed to print.
Looked at what was coming into our LPR implementation and the print job
size being given us from Windows was an astronomically huge number
Went into properties->port configuration for the Printer, checked the
'LPR Byte Counting Enabled' check box
voila... our LPR code received a proper size for the print job
did the google... Windows has been doing this goo for years, found other
folks who had encountered this, found hundreds of printer installs all
explicitly stating the 'LPR ByteCounting Enabled' checkbox be clicked as
part of the install.
What a pain in the ass... if you follow the LPR spec in your
implementation you expect a valid print job size to be passed in..
This means that your user must climb down in and figure out how to set
this checkbox and then do it for every printer built through Bonjour (if the
printer can't handle the Windows foo print job size...)
So much for the ease of use...
My guess:
Rather than first spooling the print job to a file and thereby getting
the size of the print job, Windows sends the data directly to the printer
but has no idea of the final size of the job and so sends some goofy number
(for example I have seen 125899906843000), this is a sweet speed gain,
avoiding the overhead of first spooling the job to disk to get the size
(hence the name DoubleSpool)
Anybody out there think there is any consistency to the goofy number(s)
that Windows passes in?
=====
Some thoughts on building the Bonjour Windows Print Wizard on windows
The build currently quacks on the include of <tcpxcv.h> (which it cant'
find)
Hunting around reveals that this header is part of the Windows Driver
Development Kit (only a 250 megabyte download...)
Maybe you could just put a copy of tcpxcv.h into the
'PrinterSetupWizard' folder in the next release
A hint that the 'PrinterWizard.Resources' from the Bonjour install
should be dropped into the debug folder wouldn't hurt
A hint that you have to compile the 'mDNSWindows/DLL' in the expected
flavor wouldn't hurt either
and if you got this far...
I sent out a question about the stability on Windows of the 107_1 release on
Nov. 18th, any chance I could get a response?
Dave Liu has seen the same thing, so I am not completely alone...
c'mon tawk 2 me...
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Printing mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/printing/email@hidden
