[Omniprint-user] Re: [printing-driver] proposal of what features the communication to a printer driver should support

[Mark H. <ha...@us...>]

Hi Robert,

I still think that defining a programmatic way to query the language
level is feasible.  The driver developers could come up with a
structure that describes how the language is formatted.  But you
are right in that it would be difficult and perhaps error prone.

> How do we handle printers that happily handle arbitrary paper sizes?
> Epson inkjet printers (I keep coming back to them because I understand
> them best) don't particularly care what the size of the paper is, as
> long as it's within bounds (about 8.7x1200 inches for the 870, for
> example).  And there are a number of printers that support roll feed
> paper, where this is actually of quite significant use.

How do you handle them to begin with?  One method is to define a
presentation space that is based on the size of the page.  For that,
the size needs to be known in advance and cannot be arbitrary.
User defined forms can be created for any size paper that you want
to print on.

Another way would be to receive chunks of the page with no real way
to know when it will stop and hope that the printer can handle it.
Programs that print banners would probably be coded this way.

> I think we also need to handle constraints in a more general fashion.
> Some printers may have different margins depending upon the resolution
> (or resolution plus other quality information) selected, for example.
> Most Epson printers can print closer to the top and bottom edges of
> the paper if a soft weave mode is chosen than if firmware microweave
> is.

I was thinking that the form name would have an informational part to
it that would not affect the selection if the margins change.  For
example,

   na_letter_8.5x11x0.01x0.01x0.01x0.01in   at   300 dpi
   na_letter_8.5x11x0.02x0.02x0.02x0.02in   at   600 dpi

would only need to be passed form=na_letter to be selected correctly.
Although it could accept the more ugly full name.

> It seems like a weird concept to me.  With on-the-fly output
> generation, this can be done with most inkjets, but it still feels
> very strange to me.  With laser printers, this doesn't make a whole lot
> of sense at all, and even I have difficulty envisioning a situation
> where this would be useful.  In any event, aborting a page is
> something I think we should defer.

Yes.  I agree.  It was a weird concept for me as well.  Which is why
I chose to go with the abort job path.

Mark

Take a look at the Linux Omni printer driver at
http://www.ibm.com/linux/ltc/projects/omni/