Parts of printing *do* work after all (Re: Boredom Strikes Student Programmer)

[marcel at metaobject.com (Marcel Weiher)]

On Sunday, March 3, 2002, at 10:13 AM, David Rehring wrote:

[I wrote]

>> "These targets" don't exist any longer.  Why don't you actually try it
>> instead of just assuming that I'm an idiot?

Because assuming I am an idiot is the much better working hypothesis, it 
seems.

> I believe my system started with OS X 10.1, then I installed the 10.1
> developer tools, then updated both so I'm using the latest publicly 
> released
> system and tools.

Yes, I just tried with the most current tools I have and now it works.

Hmmm....of course it did work way back when, but when I tried sometime 
in fall, I couldn't get the plugins to compile, various headers for the 
UI part were missing.  What's weird is that the bugs I filed on this 
were essentially confirmed, without there ever being a notice about a 
fix, or a change of status to "works correctly".

> While PBM's and IOM's are mostly paired together, this is not a 
> requirement.
> Several PBM's can use the same IOM.

Yes, but you always need some sort of PBM to go with your IOM.  If the 
PBM is broken and you can't write a new one (due to missing headers or 
brain-tumors or something...), you're stuck.

> PM's get to say which IOM's they can possibly work with.

Which, of course, is also something they don't necessarily know about.  
For example, the same PCL driver would work just as well spewing its 
bits to a JetDirect interface as over USB.  Or to a file, or a 
command-line program.

> PBM's get to say which IOM they work with and get to select which 
> drivers
> they work with.

This is the IOM -> PBM -> Driver dependency I am talking about.  It all 
seems to make perfect sense in the architectural diagrams, but the 
consequences are quite non-sensical.

> IOM's just sit there and transfer whatever data gets passed to them.

Except they also determine what that data may be, indirectly through the 
PBM.

> Apple could have implemented their LPR PBM to also support other 
> driver's
> besides PostScript printers.  But they chose not to, probably because of
> [note, I wasn't there, so these are just possibilities]:
>
> -UI issues [select a driver and also a PPD if user selects the 
> PostScript
> driver]

The fact that UI issues are so intertwined with basic I/O issues is the 
architectural defect I am lamenting (in addition to the plugin-approach 
and other issues).

> -effort vs. return [they probably believe that most of the installed 
> base of
> network 'LPR' printers have PostScript]

Yes, I also assume that this is the trade-off they made.  However, the 
fact that this was a trade-off they had to consider, and one that 
couldn't be easily modified points back to the architecture.

> -they plan on supporting 'sharing' printers using IPP

Yup.

I will see if I can get my stuf to work now.

Regards,

Marcel (trying to wipe egg off face)

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