[Omniprint-user] Re: [printing-cap] Re: [Inkjet-list] Re: Taking a step back

[Ben W. <be...@zo...>]

> Ultimately, you *really* want a static snapshot of what a driver can

I think that this is a bit of an implementation thing. I really don't
want a static representation.

> do.  This ideally should be a data file that can be read by a driver/
> filter (using a standard API of course) to handle any printer/job
> specific setup.  For devices whose options depend on, say, what kind
> of ink cartridge is installed, a background driver process can monitor
> the printer and update the static snapshot as needed (and obviously
> any driver would need to reject/stop a job that won't print on the
> current configuration)

I'm really not a fan of this functionality. I'd much rather have some
sort IPC mechanism rather than some sort of dropbox.

<snip> 
> Also, trying to get printer drivers and applications to talk to
> each other directly is a mistake.  It doesn't scale.  Better to

I personally think this is completely wrong. I don't see how it
doesn't scale at all.

> have the driver maintain a snapshot of the current configuration
> than to introduce potentially long round-trip times which may
> require UI intervention ("your printer is not connected or turned
> off") or have to be postponed because the device is busy.
> 

I'm not a fan of this dropbox methodology that he is advocating. I
agree that there is a problem if the printer or the printer is turned
off we need to be able to provide the user with information in a
timely manner but I still think that it needs to be provided by the
drivers.

> > ...
> > A GUI application will need to query the printer driver for its
> > strings as well as hints as to how to display the information.
> 
> Again, a *static* file makes this a lot easier.  I'm not 100%
> happy that the PPD spec only allows a single language right now,
> but others have suggested a common translation catalog that covers
> common options...
> 
> > ...
> > While inkjets may not need acceleration, there are other printers
> > that do. It is much more efficient to transfer a high level call like
> > drawing a rounded box than it is to transfer a bitmap image of that
> > box.  Some examples of high level languages are: HP-GL/2, PCL6, and
> > even Postscript. Should there be two different code paths for
> > printing to an inkjet printer vs printing to a Postscript printer?
> 
> HP-GL/2 is a waste of time.  There are too many special cases and
> too many differences in appearance between models (even within HP
> models).
> 
> PCL 6 is an option, but can be handled by existing software like
> Ghostscript without requiring the application to know about it.
> 
> PostScript, with all its weaknesses, is still the defacto standard
> printing format for UNIX apps.  Any printing solution will have to
> support it to be accepted, which is why CUPS includes a version
> of GNU Ghostscript for non-PS printers, and why we use PPDs.
> 

What ever happend PDF 1.4.

> > ...
> > One example of reducing data that is sent to the printer driver is to
> > use device fonts that are resident in the printer.  To achieve
> > WYSIWYG printing,
> > an application will have to query the printer driver for its font
> > metrics.
> 
> The printer driver is not the right place for this; the printing
> system needs to manage fonts, and provide an API for drivers to
> register/retrieve them.

Once again I think Michael and I differ here. I think that fonts
should be part of the comabilities subsystem but I wasn't pushing that
yet.

-ben

> 
> > ...
> > something that the operating system should store and tell the
> > application and printer driver.
> 
> The application should no nothing about what driver is being used,
> just what capabilities the printer has...
> 
> -- 
> ______________________________________________________________________
> Michael Sweet, Easy Software Products                  mi...@ea...
> Printing Software for UNIX                       http://www.easysw.com
> 
> _______________________________________________
> printing-cap mailing list
> pri...@fr...
> http://freestandards.org/mailman/listinfo/printing-cap