Boredom Strikes Student Programmer

[marcel at metaobject.com (Marcel Weiher)]

On Sunday, March 3, 2002, at 05:46 AM, David Rehring wrote:

> What exactly is the problem you are having with these targets?

"These targets" don't exist any longer.  Why don't you actually try it 
instead of just assuming that I'm an idiot?  Things will become obvious 
fairly quickly.

> Actually, it's the PM that decides which IOM's it'll work with, not the
> other way around.

No.  It is the PBM that decides what drivers it will allow the user to 
browse for its particular IOM.  Since there is no other documented 
method of actually installing a printer, this effectively controls what 
you can do.   IOM and PBM are paired together, so apologies if I don't 
always distinguish them clearly.

>  However, Apple's LPR PBM was implemented to only support
> UI to select PostScript printers.  I've had some discussions with Paul
> Danbold about adding a PBM that supports non-PostScript printers using
> Apple's LPR IOM and he seems to think that it'll work.

Well, it\s good to know that Apple engineers have savvied up to the fact 
that LPR is not a 'Postscript only' protocol, because that was the 
answer that I got when I pointed out the limitation of both the LPR and 
"directory services" IOMs.  Anyway, there are some additional bugs that 
would prevent that from working, for example it seems that Apple's 
LPRMIOHelper always sends the '-o' option that indicates Postscript (and 
that virtually no host-based lpd in existence can deal with, including 
Apple's own).

Sharing *all* types of printers would have been absolutely trivial in 
Mac OS X 10.0, were it not for bugs in architecture and implementation 
of the current print system.

Anyway, I have actually managed to substitute Apple LPRIOMHelper with a 
small shell-script + modified the XML queue description to specify PDF 
instead of Postscript as the output format.  This has indeed enabled 
sending PDFs via LPR to custom output filters, but it's not exactly 
something I would recommend.

>> Gosh, I sure hope they don't just add IPP as an additional output 
>> method
>> (maybe also with a force-to-Postscript feature...), but simply throw 
>> out
>> what they have now.
>
> Well, since Apple and the major printer manufacturer's have put a 
> couple of
> years work of effort into using the current system, somehow I doubt 
> they'll
> chuck it.

This is called "throwing good money after bad".  The only reason that it 
has taken this much effort is that the current architecture and 
implementation is convoluted to the point of being obtuse.  So the fact 
that it's been so much work, with such appalingly paltry results, should 
be taken as cue to chuck the architecture, instead of seeing this as an 
investment.

> My understanding of what Apple wants to do with do with IPP is to make a
> better form of printer sharing [USB printer sharing only better].

You mean like the way lpd-based printing has always worked?  If you want 
to share a printer, you just share it, such an operation being 
completely independent of the type of printer you want to share.

Marcel

--
Marcel Weiher				Metaobject Software Technologies
marcel@xxxxxxxxxxxxxx		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.