[Gnome-print] Gnome printing issues




Hello,

>    In a networked printing scenario, doing the rasterization
> client-side is potentially a huge performance problem ...

That is why printer drivers band.  The page is replayed n times to
a band that is 1/n as large.  Of course, it takes n times as long
to print, but the memory requirements are less severe.
Banding uses a journal file, which is a recording and playback of
the APIs used during printing.  It can be a different format than
the metafile.  Metafiling is used to allow the application to be
able to be used immediately after printing.  Of course, there
are instances where a user wants the printer driver to generate
the output immediately.

>    There was quite a bit of excitement at the Printing Summit about
> the open sourcing of the IBM Omni driver framework. Perhaps the most
> exciting thing was the vast archive of supported printers. However,
> in the actual release, only 100 printers are supported, from only two
> manufacturers (Brother and Epson). Since most of the driver work was
> done under NDA, presumably IBM simply failed to obtain permission from
> the printer manufacturers to release their code. I have no idea
> whether this is going to change, but until then we should be looking
> at Omni on its technical merits.

Its not that we failed.  We are working with printer manufacturers to
open source the data that they provided to us.  These things take time.

>    From what I understand, image quality in Omni is middling.

The dithering was designed to be general and support many printers (500+)
instead of, for example, making six color Epson Stylus' look great.
The dithering code is a module and can be replaced.  If there is some
LGPL code out there, we would be happy to include it.

> Newer printers such as the six-color Epsons are not supported at all.

We are working on this.  This is the second release of new code.  The
OS/2 Omni driver's code was not easily to work with and add new devices.
What we are trying to achieve with the Linux Omni driver is a framework
to easily add new devices.  One should be able to describe a device
simply through a text language.  We are halfway there.  The data is text
but the bitmap to printer language is not.  The printer working group is
designing the UPDF to describe a device.  However, they assume that the
language is already known.

>    The current release of Omni has a dependency on the IBM Java
> implementation, which appears to be based on Sun's and is not free
> software. I don't know how quickly IBM is moving to remove this
> dependency.

Actually, it has a dependancy on a JVM for the developers version that
builds driver library files.  There are a number of java compilers for
linux.  You should be able to use any of them.
What is not free about the IBM Java implementation?
However, ANTLR has the ability to use C++ and, as such, it is possible
to remove the dependancy on the Java language.
Right now, we only provide the source, but in the future we will provide
binary files so you wont need to install java.

>                                                   Most inkjet printer
> manufacturers have indicated their preference for providing binary
> Linux drivers (in one framework or another). I believe that supporting
> the Gimp Print work is our best bet for ensuring that our complete
> printing infrastructure remains free.

By that, do you mean that since Gimp Print is GPL, then printer
manufacturers would have no choice to use binary implementations for their
driver?

Mark Hamzy






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]