Re: [Gnome-print] Re: [Gimp-print-devel] An introduction to gnome-print (fwd)

[Miguel de Icaza <miguel helixcode com>]

> This is one issue that has come up before: aside from maybe providing
> a basic driver for PCL printers, I don't think the right "solution"
> is to embed drivers in the applications.  

The PCL driver just happens to be the first driver that has been
developed on top of the generic RGB rasterizer.

It is not a "basic" driver for PCL printers, it is designed to print
perfecly beautiful pages on pretty much every PCL printer in
existance.

> It doesn't scale, address "corporate" issues like accounting, etc.,
> and can lead to all sorts of problems for new drivers, etc.  See
> more below...

I looked "below" and never found anything relevant, nor a way to
sustain your claim of "not scale".  New device drivers are just new
shared library object files.  Your point?

> I agree with all of these points; remember, however, that not all
> systems use GNOME (gasp! :) and making GIMP print entirely dependent
> on GNOME might limit its usefulness on other platforms.

Well, then they would have to compile a few extra packages.  What is
the big deal?   You suggest that reimplementing all of the GNOME
dependencies into gimp-print is a better approach for the sake of
"those that dont have GNOME installed"?  It seems like the benefits
outweight the problems.

> Also, CUPS (http://www.cups.org) uses PPD files successfully with
> non-PostScript printer drivers; the PPD files are used by Ghostscript
> and our image RIP to set driver-specific options which come through
> in a header prior to the raster data for each page.

Good.  Then we just need to use modified PPD files as our "repository"
for information.  Next?

> >      Our plan is to use libppd to "import" PPD files into GNOME print
> >      profiles (check http://lists.helixcode.com, gnome-print archives
> >      for the actual proposal).
> 
> I'd be careful about "importing" PPD file data into a different format.
> In our experience it causes many problems (such as syncronizing and
> updating to new drivers/PPDs), and you're better off sticking with the
> original files.  

You can just link with PPD and expose its internals trough the same
API you would access our configuration data.

Miguel.