[Printing-architecture] RE: [printing-driver] More Vector Driver questions and Job

[Mark Hamzy]

> As for User selectable printer capabilities I
> wrote the email in response to this capability brought up in the driver
> meeting.  My support for this will be based on the feedback from these
> emails.  Actually, I currently see the printer capability as fixed (by
the
> PPD or UPDF or ???) and not having any User selection. If there are
> differing printer capabilities shouldn't there be separate descriptors!
But
> I would like to hear other individual's opinions.

PPDs have user selection in them.  They define what forms, trays, medias,
and
resolutions to use.  They can also define what hardware features are
installed
on the printer such as extra trays or a duplexing unit.

> Let me also state that I strongly believe any vector driver library
> conforming to the specification required to be fully supported all of
vector
> driver API's. It is up to the individual vector driver library to "figure
> out" how to execute each API call not do a selected few.   Otherwise it
> leaves the responsibility to a higher level process to determine how and
> to-do part of the vector rendering.   This places a requirement that
there
> be a higher level renderer process to support vector printing; why?  This
> seems to complicate the situation - it could mean a generic higher level
> renderer would have to, in theory, support all of the vector driver
API's!

Forcing a printer driver to support all high level calls will make it
harder for people to write printer drivers.  When there are a large number
of vector APIs that must be hooked out before a device is supported, it
requires that every API must be written before everything prints out.  Not
every device may support all of the vector calls.  There may even be
devices that only support a few of the calls.  Then those devices will
have to write code that simulate the non-supported vector calls into a
bitmap.  This will then mean that many devices will have the same set of
code that does this raster simulation.  Each driver can then have its own
set of bugs.

By requiring the renderer (ghostscript) to support all vector calls, it
allows drivers to support a few high level calls at a time.  This
simplifies driver development.  It also reduces bugs since the common
rendering code is within one component.  If a bug is fixed there, it will
fix every driver.

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-architecture/attachments/20040429/fd393799/attachment.htm