[gs-devel] Re: unifined GPL Ghostscrpt 8.01 release
dan.coby at artifex.com
Tue Nov 18 13:04:35 PST 2003
I thought that I would comment on one issue in that Till brought up:
>The legacy drivers must be conserved, to avoid loosing support for all
>these printers. The best would be if GhostScript had a legacy interface
>besides the main color-controlled interface.
I do not think that it is practical to try to create a version of
Ghostscript that has two separate device interfaces. The effort to
create such a dual interface would be much larger and more error prone
than simply modifying the legacy devices.
In practice, only some small changes need to be made to a few of the
device routines. The routines affected are map_rgb_color, map_cmyk_color,
and map_color_rgb. For RGB and CMYK devices, if the device is using the
default routines which is the case for many devices then no changes are
required at all. If the device is monochrome then the only change
required is to switch to a gray color handler.
The largest problem is testing the any changes that are made. Artifex
does not have the printers available with which to test.
From: gs-devel-bounces at ghostscript.com
[mailto:gs-devel-bounces at ghostscript.com]On Behalf Of Till Kamppeter
Sent: Tuesday, November 18, 2003 9:03 AM
To: Ralph Giles
Cc: gs-devel at ghostscript.com; hamzy at users.sourceforge.net;
wfink at users.sourceforge.net; Grant Taylor; bero at users.sourceforge.net;
rlk at users.sourceforge.net; pzannucci at users.sourceforge.net;
foomatic-devel at linuxprinting.org; sharkey at users.sourceforge.net;
tillkamppeter at users.sourceforge.net; Kurt Pfeifle; Robert Krawitz;
easysw at users.sourceforge.net
Subject: [gs-devel] Re: unifined GPL Ghostscrpt 8.01 release
[ I open the discussion also to the Foomatic developer list ]
Ralph Giles wrote:
> Hi folks,
> It's about time to release the 8.0x version of Ghostscript under the GPL,
a year having
> passed from the AFPL Ghostscript 8.00 release.
> In a conference call last week, it was decided that Easy Software and
> finally merge the ESP fork back with the "upstream" version, as has been
> and on for some time. The target is to have a GPL Ghostscript 8.01 release
ready at the
> end of November.
Good idea joining the two concurrent projects and so joining the
development efforts. But I cannot imagine that we succeed to join the
projects by the end of November, there are only 13 days left.
Important is that when there is only one GPL GhostScript that Mike
Sweet, me and all other contributers who had write access to the CVS of
ESP GhostScript will have write access to the CVS of GNU GhostScript, so
that they can continue adding bug fixes and drivers quickly.
> I'd appreciate any help you could offer in sorting through the various
> the GS_7_0X branch at cvs.ghostscript.com (or just the 7.07 release) at
espgs head, and
> getting those ported to 8.0x. In particular I'd like help from the
> on setting priorities for the various pieces. The minimum goal is a
> that works with CUPS, but we'd like it remain a nice distribution for
For distros it is VERY important to have all legacy/third party printer
drivers in GhostScript, as it gets a patch nightmare otherwise. Distros
must support as much hardware as possible, including older and even
obsolete printer models, otherwise users will complain. Linux is an
operating system where drivers for old hardware are not removed and so
users with old hardware can use Linux (but not Windows). It would be
also a nightmare for users when they have to patch/compile their drivers
again, when there is not the ESP GhostScript with all drivers any more.
> A brief outline of how things look to me at this point:
> - it's possible there are some security issues with 8.00, since a lot were
found in the
> development that lead up to 8.10. Ray Johnston will verify whether
anything needs to be
This is very important, if AFPL GhostScript contains a security fix, one
must make an exception from the one-year delay and port the patch over
to GNU GhostScript immediately.
> - most of the autoconf changes are good. I can handle checking them in.
With autoconf GhostScript is much easier to install and selecting
drivers to compile in is also easier (distros can simply select "all"
for all drivers).
> - CUPS raster goes in obviously.
Then there will be no confusion any more with a GNU GhostScript not
containing the "cups" device (when every distro compiles GhostScript
against the CUPS library.
> - the stp device will not be included. It's been deprecated by the
gimp-print people in
> favor of the ijs (or CUPS) interface for some time, and doesn't build with
> 4.3.5 and up.
No problem, I have also obsoleted "stp" in Mandrake 9.2, it had a bug
and I have simply surrounded the bug by using the IJS interface.
> - there was never an AFPL 8.01 release, so there are a probably a number
of bug fixes in
> HEAD that will want porting. As usual we'll consider such requests on a
> - some of the changes in esp seem to be spurious or 'quick fixes'. While
> policy for the GPL branch at ghostscript.com is very much more relaxed
than for HEAD,
> I'd still like to sort some of these out and fix the actual issue the
> Another reason I'd like help with the priorities from packagers.
> - the hardest question is I think the plethora of legacy drivers that have
been added to
> ESP Ghostscript. I like the idea of having the more unsupported ones in a
> contrib/ and of having a centralized distribution of all the various and
> that have been written over the years. On the other hand, updating all of
these for the
> changes to the color mapping routines in 8.0x (necessitated by devicen
support) is a
> fair chunk of work, especially given the testing issues, and we have in
> trying to get away from shipping large numbers of drivers and instead take
> generic and protocol devices to move the drivers out of ghostscript. The
> policy with the GPL branch was to only include drivers that did not have a
> alternative (gimp-print, hpijs, pxl, etc.) support option, but I'm open to
The legacy drivers must be conserved, to avoid loosing support for all
these printers. The best would be if GhostScript had a legacy interface
besides the main color-controlled interface. So the users of old
printers could at least print, they do not need the color control. The
legacy interface could either be compiled into GhostScript and allow
compiling GhostScript with legacy drivers or it could be an IJS module
wrapper and so one or a few legacy drivers could be compiled to an IJS
module and the whole set of legacy drivers is provided by a set of IJS
modules, making the main executable of GhostScript smaller. So the
legacy drivers could be loaded only when needed. Disadvantage is that
one would need to adapt the Foomatic data, but this could be done by a
script. All drivers which are still actively maintained should be
switched to IJS. The legacy interface should only be used for drivers
which are not maintained any more or for drivers which are not switched
to IJS yet.
It would be very ugly if older printers will not be supported any more
or if an extra "Legacy GhostScript" must be maintained and added as a
second GhostScript to all distros to conserve device support.
All new drivers should naturally be made as IJS modules and not as
compile-in drivers, so that driver development can be done independently
of GhostScript and users do not need to patch/rebuild GhostScript.
> Anyway, let me know your thoughts.
> Ralph Giles
> GPL Ghostscript maintainer
Robert L Krawitz wrote:
> Date: Tue, 18 Nov 2003 03:41:45 +0000
> From: Ralph Giles <giles at ghostscript.com>
> - the stp device will not be included. It's been deprecated by the
> gimp-print people in favor of the ijs (or CUPS) interface for some
> time, and doesn't build with versions 4.3.5 and up.
> I heartily concur with this. It's time to get rid of this once and
> for all. We introduced our IJS driver in 4.2.1 (April 2002) and the
> last bugs to have been fixed were in 4.2.3 (October 2002). If anybody
> really needs this they should get it from the 4.2 Gimp-Print
In Mandrake 9.2 "stp" is history.
> One question, though: do you plan to distribute the Gimp-Print IJS
> - the hardest question is I think the plethora of legacy drivers
> that have been added to ESP Ghostscript. I like the idea of having
> the more unsupported ones in a separate contrib/ and of having a
> centralized distribution of all the various and sundry devices that
> have been written over the years. On the other hand, updating all
> of these for the changes to the color mapping routines in 8.0x
> (necessitated by devicen support) is a fair chunk of work,
> especially given the testing issues, and we have in general been
> trying to get away from shipping large numbers of drivers and
> instead take advantage of generic and protocol devices to move the
> drivers out of ghostscript. The previous policy with the GPL branch
> was to only include drivers that did not have a newer alternative
> (gimp-print, hpijs, pxl, etc.) support option, but I'm open to
> discussion on that.
> There isn't likely to be time to do this if you want to release in a
> few weeks, but you might want to determine which of these drivers are
> used and which aren't and port forward the most extensively used such
> drivers. The next step would be to start a public project by which
> you would solicit people to create IJS-based drivers for any driver
> they care about.
Yes, all existing drivers which are maintained by someone should be
switched to IJS, for unmaintained drivers there should be a legacy
interface, best as a special wrapper IJS module, as I told earlier. We
must conserve these legacy drivers to avoid users complaining about
support for their printers being stopped and to avoid to run a second
GhostScript project for legacy drivers.
The only drivers which we can remove are drivers whose printers are all
supported by a better driver, as "cdj970", all the printers using this
driver get better support from HPIJS. One simply needs to search for
driver entries on linuxprinting.org which are never "recommended driver"
for any of the supported printers.
> Another thing that I think should be considered, for a future release,
> is incorporating appropriate parts of Foomatic into Ghostscript. An
> important use of Foomatic is to simplify the use of Ghostscript with
> spoolers, particularly legacy Ghostscript ones. Perhaps this would
> mean merely distributing the appropriate Foomatic data, but that
> should be open to discussion.
One could move all driver/option XML data for drivers which come with
GhostScript into the GhostScript project, GIMP-Print, HPIJS, and OMNI
contain also their driver/option XML files. Printer entries should stay
on linuxprinting.org as one printer can be served by well different
drivers. So in the end the foomatic-db package on linuxprinting.org will
contain only printer entries, all other entries are part of the
GhostScript or driver packages.
Should perhaps even the web sites of GNU GhostScript and
linuxprinting.org be moved closer to each other, as for example
hosting/mirroring of GNU GhostScript on linuxprinting.org or having a
mirror of linuxprinting.org at GhostScript?
gs-devel mailing list
gs-devel at ghostscript.com
More information about the gs-devel