GNOME.org
 

[Gnome-print] [Fwd: Gnome printing issues]

 

about gnome-print-admin.

I am making the printer database backend for gnome-print extensible
so that it can be used to configure printers in diferent systems. I
have talked about it with Robert Krawitz and he is interested [1]
in it too. It should not be too hard to hook up to other printing
systems, say Cups or Ghostscrupt. This will be very nice for a number
of reasons, one of them that the users will not have to configure
their printers more than once, since the same database will drive
different systems . It is not yet finished tho, but
I am working hard on it. [ cvs module "gnome-print-admin" ]

Without too much extra effort it will be able to :

1. Serve as gimp-print's database

2. Emmit "/curentpagedevice" fragments in Postscript for
ghostscript rendering when printing from gnome-print powered
apps.

3. Add the "/curentpagedevice" fragments from postcript output
not generated by gnome-print. Similar to what ben Woodard
did with lpr & gpr.

[1]- Interested as in "Yes, that sounds like something we should
consider/take a look."

>    Some of you know by now, but probably many do not, that I am taking
> over the maintainership of Ghostscript. 

This are good news. 

>    Thus, I'm fairly convinced that we should be using existing
> standards such as PDF, and existing implementations, such as
> Ghostscript, rather than trying to invent our own solution. In simple
> cases, such as a desktop computer running only Gnome, with a locally
> attached printer, there isn't much difference. The differences become
> significant as you move to more complex scenarios.

Raph as you are aware there are some problems with ghostscript.
Ghostscript compiles on every other OS out there, so coding has
to be done very carefully. As I understand it, we can't even add
glib as a dependency. ( Is this correct ? )

>    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).

The OMNI team will support more and more devices in a very rapid
pace. They have 4 engineers working full time. I am expecting for the
list of OMNI suported printers to grow.

> 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....

Yes, this is changin.

>    From what I understand, image quality in Omni is middling. Newer
> printers such as the six-color Epsons are not supported at all. Of
> course, it should be possible to fix this, but somebody (who?) has to
> write the code. Much of the code already exists in GPL form (both my
> rinkj experimental Epson drivers and the Gimp Print work),

I talked to them last week and they are implementing variable dot size
and six-color printing for Epson printers. They expect to have it
working for the next release. Keep in mind that OMNI 0.1 was released
August 14th, and 0.0.2 august 21th, not even a month ago.

OMIN is not something that they gave away and left it floating there.
It is a project which is and will be activelly maintained. IBM is
interested in solving the printing problem in Linux too. They have
a LOT of experience which we can leverage from.

>    From the Printing Summit presentation, Omni has a very nice data
> driven database for configuring printers. This is a good thing, as the
> other frameworks bind printer configuration pretty tightly to the
> code.

Oh, the OMNI team is also interesed in Merging gnome-print-admin with
their database system. 

>   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.

Yes, this is a problem (the RPM is like 10 Mb). I have not talked to 
them nor investigated further on this. I do not know how much is
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.

>    Miguel has told me that there have been difficulties working with
> the Gimp Print team. If so, I would like to see these problems
> resolved. My conversations with Robert Krawitz have left me with the
> impression that they are very serious about providing a general
> solution and not just a system for printing pictures from Gimp.

The main problem that gimp-print is the License, they are not interested
in merging their proyect with a LGPL proyect, they want to keep their
code GPL. *NOT* that the licensing model is wrong at all !!!, just that
it is something that can't be mixed with LGPL code. ( I am thinking
about
merging with OMNI for example )

My conversation to Robert is that they are not interested in anything
other than programs that print a bitmap. I think he mentioned that
he was not interesting on adding labels to gimp output. Gimp-print's
focus might have changed. ( I could search for the email from which
I got this impression )

On the other hand they do solve the problems of going from a rendered
bitmap to paper with good quality.

> Lauris already has some of
> the higher-level frameworks in place in his gnome-font project. I
> don't have the time to be doing this work myself, but would be more
> than happy to help people integrate it.

We should not be working on a separate font solution. This efforts
should not be part of diferent projects/modules.


- The framework -

Ok, ghostscript is very good for some stuff and has some shortcommings.

One of the parts of ghostscrip that needs fixing is the drivers.
As you stated before the code is 
1. non modular
2. ugly
3. Code driven 
Each driver usually implements it's own dithering code, and the
printer information is hardcoded inside it.

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).

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.


Chemas Dream Roadmap :

1. finish gnome-print-admin, and hook it with the current set of 
gnome-print native drivers.

2. Implement the PPD import feature and start generating PS code
with aditional printer features (using gnome-print-ps2 ).

3. Start controlling printer features for ghostscrip drivers 
(OMNI drivers going thru ghostscrip) from withing gnome-print.

4. Port another printing system to gnome-print-admin as a printer
database. Either gimp-print, Cups, GS or OMNI.

5. Implement the ability to add the PS code fragments to PS
output generated by non-gnome-print apps. Kinda like gpr/lpr
from the VA guys.

6. Win the loterry, trow a big party, get maried and live 
happily ever after. Buy a small plane and go on a skydiving
tour all over the world.
 

regards,
Chema

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