[Gs-devel] Re: GNU/ESP Ghostscript

[rillian]

On Wednesday, May 30, 2001, at 07:36 , Michael Sweet wrote:

> Well, there are a bunch of things that we'd like to do on the GNU
> Ghostscript front; here's a quick run-down of the list:
>
>     1. Provide a central repository of drivers and patches from
>        the various Linux/BSD distributions.
>     2. Provide a drop-in replacement for the pstoraster filter
>        included with CUPS so that one Ghostscript distribution
>        can support both CUPS and non-CUPS printing.
>     3. Provide a more modern autoconf-based configuration
>        script to make building Ghostscript easier and more
>        reliable.
>     4. Integrate the latest GIMP-print (and other) drivers for
>        photo-quality printing.
>     5. Provide spec, list, etc. files to standardize the
>        packaging of Ghostscript.
>     6. Update to the latest GNU versions as they are released by
>        Aladdin
>     7. Add support for dynamically loadable Ghostscript drivers.
>        The current "compiled everything in" model just doesn't
>        scale, and the OMNI/HP driver architecture isn't suitable
>        for all drivers.
>     8. Add support for ICC-based color management.

Ok, this all sounds reasonable. For our part, 1,5, and 6 fall under the 
"GNU Ghostscript maintainer" job Raph mentioned in his post. And I'm 
very happy to report I've finally gotten permission to include autoconf 
support in the mainline code, though only at the level of the 
platform-specific makefiles. And break the code into subdirectories. So 
that's certainly coming in gs 8.00, and can probably be backported.

The rest I can't really comment on, maybe someone else can address them. 
Certainly we'd look at any patches you generate. :) Dynamic drivers is 
something we've discussed in the past, but I think the plan is leaning 
more toward running the driver as separate process at the moment.

Would you be interested in working up any of these bits you've done as a 
patch against GS_6_5? I don't know how long raph wants to hold the 
release, but we could certainly do a 6.52 a bit later. The hpijs and 
omni integration is all new to the GNU release, so there will probably 
be bugs to fix in any case.

> As for bringing the AFPL and GNU branches closer, my main concern
> is possible code pollution; that is, if the code is maintained
> in the same repository, there is the chance that some AFPL code
> will end up in the GPL branch, and visa-versa.  Many of the
> drivers and patches to the GPL branch cannot be applied to the
> AFPL branch because they are GPL'd...

Certainly. That could be something we watch for in code review. 
Traditionally the GPL releases have been a tarball-only thing, but it 
sounds like it would be good to actually maintain such a thing in cvs, 
especially if people are willing to look after it.

How allergic are you to the AFPL/Artifex flavors? I can certainly 
understand the urge to fork over the neglect of the GNU release, but for 
example, the current AFPL release 7.00 already has half of the ICC 
support implemented, so adding that to the 5.50 or even 6.51 releases is 
already duplicated effort. We'd love to have you help out on the AFPL 
version instead, if you're willing to trust that we'll eventually free 
the relevant codebase.

> I also think that if we continue developing the GNU Ghostscript
> branch, at some point it will become impossible to merge new
> GNU releases into the branch.  In particular, we have a vision
> of a less-monolithic RIP architecture which will dramatically
> change how Ghostscript operates internally.

Raph is planning to modularize things too, but it's going to take a 
while. You're right, keeping up with upstream in the case of a real fork 
would be major, major work.

Thanks for writing back so quickly,
  -ralph