[Gnome-print] Re: Gnome printing issues

[hamzy us ibm com]

Hello again,

> Java beeing used inside. I know the parser is written in java, and
> if the database is replaced/merged they migth be able to drop
> this dependency. As I said, we need to investigate further.

Java is not used as a database.  It is used to generate printer driver
code from the database entries.  I would like to understand why Java
cannot be used.
I dont want to start a language war. ;)  I happen to use both.

> Each driver usually implements it's own dithering code, and the
> printer information is hardcoded inside it.

Until dithering code takes into account the printer's ink colors and
paper types in a format that the printer vendors supply, you will
still include special dithering/halftoning code that produces
the best output for the device.

> On the other hand the OMNI driver architecture is modular and
> database driven, but it doesn't have a renderer. And it's
> also free software (yes, we need to solve the Java issue).

Because one uses Java, it is not free?

> So .. why do we fix (rewrite) the drivers in ghostscript if the
> OMNI architecture is better ?
>
> What i'd like to see is gnome-print using the OMNI drivers for
> driving ink-jet printers, and use either the ghostscript
> renderer or libart renderer (If you prefer to use the gs renderer,
> it's fine with me, lets use it) . We don't have to commit to one
> renderer rigth away, since the OMNI drivers are not strongly tied
> to a renderer.

Under OS/2, the render was a graphics engine that had multiple levels
of simulation.  For example, a program draws a rounded box.  If the
driver did not hook out the rounded box call, the engine would see if
the driver supports PolyFilletSharp.  If not, the fillets are reduced
to PolyLines, and so on.  Text could be hooked out if a device font
was used or it could be transformed into a downloadable font and
hooked out or it would be rendered into the bitmap.  There are many
more examples.

Mark Hamzy