Slackware has changed to ESP because it brings more
drivers and has a better integration with CUPS

Well, the drawback is that you end up being further removed from the
origin of the source code. The benefit is that someone else does (a
lot of) the integration for you.
Does ESP Ghostscript include the patches for Japanese support, out of
interest? What are the differences between the ESP Ghostscript
package and our package based on GNU Ghostscript (which has lots of
patches)?
Which direction should Fedora Core take for ghostscript? Now is a
good time to discuss that, since we're overdue to jump to version 8.
Tim.
*/

On Fri, Oct 15, 2004 at 10:36:35PM +0200, Xose Vazquez Perez wrote:
> what's the ghostscript future in FC ?
>
> GNU Ghostscript http://www.ghostscript.com/doc/gnu/
> http://www.gnu.org/software/ghostscript/
> ESP Ghostscript http://www.cups.org/ghostscript.php
Good question. Well, what do we all think?
> GPL Ghostscript http://sourceforge.net/projects/ghostscript/
This site is no longer current, by the way. The GNU Ghostscript
project is the same thing at GPL Ghostscript.
> Slackware has changed to ESP because it brings more
> drivers and has a better integration with CUPS
Well, the drawback is that you end up being further removed from the
origin of the source code. The benefit is that someone else does (a
lot of) the integration for you.
Does ESP Ghostscript include the patches for Japanese support, out of
interest? What are the differences between the ESP Ghostscript
package and our package based on GNU Ghostscript (which has lots of
patches)?
Which direction should Fedora Core take for ghostscript? Now is a
good time to discuss that, since we're overdue to jump to version 8.
Tim.
*/
______________________________________________________________________
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

wrong, 'GPL Ghostscript' is the package relased by artofcode, LLC. and
Artifex Software, Inc. from an old tree of the commercial 'AFPL Ghostscript'
under GPL license.
'GNU Ghostscript' is 'GPL Ghostscript' minus some "questionable"
files.

Does ESP Ghostscript include the patches for Japanese support, out
of
interest? What are the differences between the ESP Ghostscript
package and our package based on GNU Ghostscript (which has lots of
patches)?

>Does ESP Ghostscript include the patches for Japanese support,
out of
>interest? What are the differences between the ESP Ghostscript
>package and our package based on GNU Ghostscript (which has lots of
>patches)?
AFPL -> GPL -> GNU -> ESP

Okay -- but what are the differences between ESP Ghostscript and the
Ghostscript package we actually ship? Ours is based on GNU
Ghostscript, but has lots of other patches integrated. What
functionality would need to be ported to ESP Ghostscript to maintain
the same level?

But these are relative to what? GNU Ghostscript? What I'm personally
interested in is a comparision between ESP Ghostscript and the
Ghostscript package we are currently shipping.
With respect to switching to ESP Ghostscript for the next development
cycle, one drawback that seems immediately apparent is that ESP
Ghostscript is not based on GNU Ghostscript 8.x! If we stick to GNU
Ghostscript we'll be able to upgrade to 8.x.
Tim.
*/

yes, GNU.
And the main differences GPL vs. GNU are that GNU deletes all files from
Resource/CMap/* because they are:
%%Copyright: -----------------------------------------------------------
%%Copyright: Copyright 1990-1996 Adobe Systems Incorporated.
%%Copyright: All Rights Reserved.
%%Copyright:
%%Copyright: Patents Pending
%%Copyright:
%%Copyright: NOTICE: All information contained herein is the property
%%Copyright: of Adobe Systems Incorporated.
%%Copyright:
%%Copyright: Permission is granted for redistribution of this file
%%Copyright: provided this copyright notice is maintained intact and
%%Copyright: that the contents of this file are not altered in any
%%Copyright: way from its original form.
%%Copyright:
%%Copyright: PostScript and Display PostScript are trademarks of
%%Copyright: Adobe Systems Incorporated which may be registered in
%%Copyright: certain jurisdictions.
%%Copyright: -----------------------------------------------------------
plus some adaptations of documents (GPL -> GNU, Linux -> GNU/Linux , GPL
license...) And GNU is one or two releases behind GPL.

With respect to switching to ESP Ghostscript for the next
development
cycle, one drawback that seems immediately apparent is that ESP
Ghostscript is not based on GNU Ghostscript 8.x! If we stick to GNU
Ghostscript we'll be able to upgrade to 8.x.

And the main differences GPL vs. GNU are that GNU deletes all files
from
Resource/CMap/* because they are:
%%Copyright: -----------------------------------------------------------
%%Copyright: Copyright 1990-1996 Adobe Systems Incorporated.
%%Copyright: All Rights Reserved.
%%Copyright:
%%Copyright: Patents Pending
%%Copyright:
%%Copyright: NOTICE: All information contained herein is the property
%%Copyright: of Adobe Systems Incorporated.
%%Copyright:
%%Copyright: Permission is granted for redistribution of this file
%%Copyright: provided this copyright notice is maintained intact and
%%Copyright: that the contents of this file are not altered in any
%%Copyright: way from its original form.
%%Copyright:
%%Copyright: PostScript and Display PostScript are trademarks of
%%Copyright: Adobe Systems Incorporated which may be registered in
%%Copyright: certain jurisdictions.
%%Copyright: -----------------------------------------------------------

I just saw that Fedora brings a patch (adobe-cmaps-200202.tar.gz) with the files
that are deleted from GNU ghostscript. So it's better to use GPL ghostscript
than GNU ghostscript.
--
Hello, this is Darl McBride, and I pronounce Linux as UNIX.

I know that *currently* Fedora Ghostscript is based on GNU Ghostscript
7.07 -- that's because I just haven't had the time to port all the
patches. But in principle someone from the Fedora Community could do
that, or it could be made a blocker/target for the next development
cycle, etc. Whereas with ESP Ghostscript we would be reliant on ESP
to do the work.
The other way of looking at it is that ESP would do the work and we
wouldn't have to. :-)
Just want to figure out which is more appropriate for Fedora Core.
Tim.
*/

The other way of looking at it is that ESP would do the work and we
wouldn't have to. :-)
Just want to figure out which is more appropriate for Fedora Core.

I don't know the ESP people, but from my POW their fork could easily
turn into something like the ximian oo.o fork (ie a staging area where
distros pool patches instead of reinventing the wheel in their little
linux corner and massively duplicating efforts).
Of course I may be horribly wrong;)
Cheers,
--
Nicolas Mailhot

I don't know the ESP people, but from my POW their fork could
easily
turn into something like the ximian oo.o fork (ie a staging area where
distros pool patches instead of reinventing the wheel in their little
linux corner and massively duplicating efforts).
Of course I may be horribly wrong;)

the big trouble is AFPL upstream code is not under GPL license so
it's impossible to merge patches into it. And the only one option
is to maintain an external patch(or repository) as Fedora or ESP are doing.
And doing sync with new GPL releases.
Or a _real_ fork.
--
Hello, this is Darl McBride, and I pronounce Linux as UNIX.

Nicolas Mailhot wrote:
> I don't know the ESP people, but from my POW their fork could easily
> turn into something like the ximian oo.o fork (ie a staging area where
> distros pool patches instead of reinventing the wheel in their little
> linux corner and massively duplicating efforts).
>
> Of course I may be horribly wrong;)
the big trouble is AFPL upstream code is not under GPL license so
it's impossible to merge patches into it. And the only one option
is to maintain an external patch(or repository) as Fedora or ESP are doing.
And doing sync with new GPL releases.

This seems much the same problem that with oo.o. Linux distos use a
common fork because it is difficult to get code into the main trunc, and
obviously Sun people work for Solaris StarOffice users first, and Linux
OpenOffice.org users later, so the priorities are not the same.
Similarly getting code into gs require upstream noticing (and getting
authorisation to use) a patch, merge it into their main version, and
_then_ wait for the next version so this one can be freed/gpl'd. Same
problem -> different priorities, long wait -> huge patch queue.
Getting patches in a common free fork would make it easier for upstream
to find them, and provide a common root so fixes can be propagated
quickly among free systems.
Cheers,
--
Nicolas Mailhot

Similarly getting code into gs require upstream noticing (and
getting
authorisation to use) a patch, merge it into their main version, and
_then_ wait for the next version so this one can be freed/gpl'd. Same
problem -> different priorities, long wait -> huge patch queue.
Getting patches in a common free fork would make it easier for upstream
to find them, and provide a common root so fixes can be propagated
quickly among free systems.

This is certainly quite a big pull for us to move to ESP Ghostscript,
IMHO.
There is also a community push to re-base ESP Ghostscript on GNU
Ghostscript 8.15.
Perhaps the best thing would be to switch to ESP Ghostscript first
(and iron out any problems that we come across) -- and then help with
the upgrade to 8.15.
Opinions?
Tim.
*/