Re: [Gnome-print] Gnome-print colors, gradients proposal

[Chema Celorio <chema ximian com>]

I am happy on how you are doing things, specialy the improvements
you have been making in gpa. My only concern was that focusing on
color spaces at this moment is not the best use of our resources.
We should work towards the next milestone which (IMHO) should be
better printer configuration and setting job options. It is very
hard to set up a printer to work under linux/GNOME at this moment.
Users are complaning more about printer configuration than
color management. Color management is important if you are going
to do either graphic arts or you want to print pictures. But for
the normal word processor/spreadsheet/email/browser this is not
a showstopper.

Now you raise a good question, which is how much of this should 
be in XST. I would love if we can divide the task between XST and
gnome-print. We need printer configuration in XST because not all
of the apps are GNOME apps, and users want to print from netscape,
mozilla, open office or ghostview.


Lauris Kaplinski wrote:
> 
> Hello Chema!
> 
> Well, I would consider PPD imports much more lower priority than
> colorspaces or gradients. 99% of your users do not have PS printer,
> but instead some raster-only device, driven through ghostscript.

Well, i respectfully disagree.
We don't need to agree on everything ? right ;-).

The rationale behind it is that i don't think they current problems
the users have are quality related. The current problems in my view
are :

1. Setting up a printer and default options, finding the "right" config
that will work with your printer. (some suported printers might require
the user to compile and patch ghostscript. NOT FUN !)
2. Setting job options right before print time. Paper tray, paper size,
resolution.
3. A good spooling system. manipulating/tracking jobs in the spooler
4. Network printing
5. Printing quality

> Well, to be more constructive.
> I started by integrating gpa fully with gnome-print. I absolutely refuse
> maintaining yet another loosely tided module, that builds into separate
> library, because gnome-print is too heterogenous even without that.
> Take a look into OpenOffice drawing code, and think, do we want such
> future for any gnome library?

I don't think moving gpa inside gnome-print was a bad idea given the
situation. I agreed with you when you did the move.

> Now, lately I started to doubt about some ideas.
> It seems to me, that the whole Vendor -> Printer part of equation has to
> be removed from gnome-print. Gnome-print should not deal with adding
> printers etc. You may want to put that part into XST, as it has to deal
> with whatever backends etc. - gnome should not add its own printers,
> but USE sytem provided printers - being these printcap entries or
> something else. If you add printer, having plain lpr as spooler, you
> certainly want to create printcap entry, some more informative xml
> file is only extra sugar.

This is a very good idea. We would just need to sort out the 
details and how gnome-print will get the information from the system.
I am still not sure where to draw the line, but you are right about
gnome-print maybe not beeing the right place for this.

> Now it would be useful, to have settings part of equation inside
> gnome-print, to have tighter integration and slicker code. But the
> thing needed here, is really a 4-fold interface
>
> - loading defaults from printer
> - read/write actual to some other place
> - read/write individual settings for GUI
> - read for actual job/spooler/whatever driver
>
> It is the interface. Not necessarily the real thing, which may
> lay inside extrnal library (or many exteranl libraries).
> I am loosing point...
> Well there a 2 possibilities:
> 1. gpa as standalone library, external to gnome-print. Gnome-print
> may use its interfaces, how exactly internally, is implementation
> detail.
> Pros - easier to integrate with system, separate maintainership
> Cons - there is no such...
>
> 2. gpa is fully integrated into gnome-print. What we need here,
> are modular drivers for almost everything, as we have to keep in sync
> with the real system configuration
> Pros - easier to implement
> Cons - looser integration with system. There is no such...
> OK. Enough of ranting, what to do?
> Printers have to be set up by module, that does system abstraction.
> So XST?
> Bang!
> What if user prefers to hand-edit printcap, use QtCUPS or something?

I am not concerned about users hand-editing printcap. If the edit it
by hand they should know what they are doing. 

> Should we make using XST requirement for using gnome-print?
> Or implement system-abstraction layer for gnome-print?

I think what we could do is have XST write a configuration
file for gnome-print to read. This will provide a file with
installed printers and default options. Gnome-print will take
care of modifying job options in the dialog.  So XST 
will do what the old gnome-print-admin binary used to do.

Gnome-print will not be required to talk to the printer drivers
directly, it will will just read whatever XML XST wrote as the
configuration.
This is not a problem from our arquitecture  and it fits nicely
because when a user configures a printer we will set up the
ghostscript printers for non gnome-print jobs and write the XML
configuration for gnome-print powered apps. So XST will talk for
example to OMNI and write the XML file it will also import PPD
files and write the options for gp to read.

About making XST a requirement for gnome-print : i don't think
this is necesary. If gnome-print can't find a printer configured
to use, we can just hardcode the postscript backend without
anything special (there is some code that already does that,
inside gpa). But if the user wants to configure a printer he
will need XST. If we make gnome-print depend on XST then the
depencency chain just grows and grows.

> Or force gnome-print users to use CUPS or something similar?

Choosing a particular spooler althou not the "right thing (tm)"
to do might solve a lot of problems. I think we should first
configure lpr and then add CUPs functionality, this will be done
in the XST way so we will use whatever is installed and will have
code to deal with both spoolers.

> Now, having abstraction layer (or xml printer definitions,
>   configuration is realtively straigthforward).
> So we can go on, implementing temporary quick-hack for creating
>   xml printer definitions
> Which happens in gpa
> But I am very much concerned about extensibility. This is, why
>   I am working on very-very high abstraction for gnome-print side.
> So we can actually switch underlying system, without affecting
>   gnome-print drivers and application interface.
> This is all about tightly integrated gpa/gnome-print (into single
>   library + loadable driver etc. modules).

sounds good.

> If you think, we can go faster, by picking up your existing gpa
>   code, make first move - release it, as separate library. It may
>   be possible to pick it up and drop great deal of abstraction, if
>   final interface is good enough. I have several concerns about the
>   interface, what I am currently working with:
> - arbitrary depth option tree
> - get rid of GUI hints in options
> - module hooks for driver and transport
> - way to specify custom gui modules
> - ...


I suggest that we leave libgpa inside gnome-print and xst write the
configuration file for it. the printer database will no longer
be part of gnome-print since we need to sync this with the non-gnome
printer configuration. So gnome-print loads and reads its config
from a specified location.

About "module hooks for drivers and transport" and "a way of specifing
custom gui modules", I don't think we need to fix this problem at
this stage, lets keep the objectives as small as possible and when
we reach the milestone set, we can set new objectives and improve 
upon what we did. Custom gui modules is advance fucntionality in
my oponion. About "arbitrary depth" this is a good thing to fix
at this stage. What do you mean by "get rids of gui hints in options ?".

I also would like to move the spooler problem outside of gnome-print
if possible. The way i think we can do it is to have a binary/shell
script called "gnome-spooler" which gnome-print will send the data
to. We can have a flag which specifies the format of the data, like
"--data=[postscript/pdf/gnomeprintmetafile/final]"
postcript, pdf are obvious
metafile is an intenal metafile to be used when
we do network printing 
and final is printer ready output, data that should go
to the printer unmodified.

This gnome-spooler can then call whatever spooler XST was
configured to use, lpr cups or something else if we need in
the future.

Any thoughts ?

Chema