Bug 690009 - New "cairo" output device pulls X dependency into main executable/library
Summary: New "cairo" output device pulls X dependency into main executable/library
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Other Driver (show other bugs)
Version: 8.63
Hardware: All Linux
: P4 critical
Assignee: Chris Liddell (chrisl)
URL:
Keywords:
: 691450 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-08-11 02:17 UTC by Till Kamppeter
Modified: 2010-07-31 16:09 UTC (History)
3 users (show)

See Also:
Customer:
Word Size: ---


Attachments
patch to make the cairo device built as a dynamic module (4.32 KB, patch)
2010-07-05 02:05 UTC, Hin-Tak Leung
Details | Diff
patch to make cairo device built as module (5.40 KB, patch)
2010-07-12 04:27 UTC, Hin-Tak Leung
Details | Diff
A better cairo dynamic module patch (4.63 KB, patch)
2010-07-27 11:21 UTC, Hin-Tak Leung
Details | Diff
carios dynamic module patch (7.30 KB, patch)
2010-07-27 12:21 UTC, Hin-Tak Leung
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Till Kamppeter 2008-08-11 02:17:30 UTC
With the merger of GPL Ghostscript with ESP Ghostscript (GPL GS 8.60) I have
introduced a mechanism to modularize the X display drivers to make the core
executable ("gs") and/or the core library ("libgs") of Ghostscript not dpending
on X, so that it does not pull the X libraries on X-less servers. Now with
version 8.63 this facility gets worthless due to the new "cairo" output device
which pulls X through the dependencies of libcairo.

My suggestion to fix this problem is to move libcairo into the module of X
output devices or into its own module to give the needed flexibility for
distribtion packaging.

I have marked this "critical" as distributions cannot accept Ghostscript 8.63
this way. They cannot make a full-featured Ghostscript and an X-less Ghostscript
without making two core executables/libraries of ghostscript.
Comment 1 Till Kamppeter 2008-08-11 02:27:19 UTC
Small correction: I mean to move the "cairo" output device into the X output
device module or into its own module, not libcairo.
Comment 2 Ralph Giles 2008-08-11 11:00:41 UTC
I think this is reasonable. Or moving to generalized driver modules that can be
built separately as we've discussed in the past.

However the cairo output device in 8.63 is experimental and not very useful. I
would suggest just disabling it for this release in packages where this is a
problem. Distributing the bug fixes are considerably more important.
Comment 3 Hin-Tak Leung 2010-05-04 22:55:41 UTC
Till: could you provide a patch for this?
Comment 4 Till Kamppeter 2010-05-06 07:29:06 UTC
No, I do not have any patch. In the Ubuntu packages I have simply disabled the Cairo output device ("./configure ... --disable-cairo ...").
Comment 5 Hin-Tak Leung 2010-05-21 04:16:09 UTC
E-mail from Behdad:
> The cairo device is basically just a proof-of-concept right now.  I don't know
> of anyone who uses that.  Indeed, it doesn't support text or any other thing
> beyond simple vector graphics.
Comment 6 Till Kamppeter 2010-05-24 20:50:54 UTC
I suggest that the "cairo" output device should be clearly marked as experimental and not being built by default (requires explicit "--enable-cairo") in future versions of Ghostscript.
Comment 7 Hin-Tak Leung 2010-07-05 01:30:32 UTC
re-assign to reporter to test patch. Patch to follow.
Comment 8 Hin-Tak Leung 2010-07-05 02:05:08 UTC
Created attachment 6426 [details]
patch to make the cairo device built as a dynamic module

The patch converts the cairo device into a dynamic module like X11.so, as well as fixing a few problems with the X11.so dynamic module which has not been noted since the ESP merge.

CC_SHARED is only used for generating object files (rather than linking) so DYNAMIC_CFLAGS is meant. 

This also changes a few $(GLCC) into $(GLCCSHARED) (addition of shared-library needed object cflags) for a few targets which the X11.so needs.

BTW, dynamic module support entries for both Mac OS X (Darwin) and SunOS looks a bit wrong - For Mac OS X, the X_DEVS variable is emptied but there is no corresponding DYNAMIC_DEVS; For SunOS, -KPIC seems a sunstudio compiler (not gcc) flag, but "-shared" elsewhere for dynamic module support is a gcc-ism. But I guess we'll have to wait for active users for either platforms who want dynamic module support for those platforms to work to test for changes/updates.

Please test if it works as intended (I tried the sympliest "./configure", " ./configure --enable-dynamic" and a few combinations of make/make so - you probably have a few more configure flags added in).
Comment 9 Hin-Tak Leung 2010-07-11 22:59:31 UTC
*** Bug 691450 has been marked as a duplicate of this bug. ***
Comment 10 Hin-Tak Leung 2010-07-12 04:27:21 UTC
Created attachment 6458 [details]
patch to make cairo device built as module

baside what's in the earlier attachment 6426 [details], a little refinement is needed to define CC_SHARED for the windows targets, otherwise they break. 

Apparently Ralph came up an identical change to 
http://bugs.ghostscript.com/attachment.cgi?id=6452 (bug 691450) in r8257 but had to back out in r8270 because of the same issue with CC_SHARED needed for the windows targets. 

so Bug 691450 is not new and has been a known problem for at least 3 years.
Comment 11 Hin-Tak Leung 2010-07-27 11:21:26 UTC
Created attachment 6559 [details]
A better cairo dynamic module patch

A better cairo dynamic module patch, together with some bug fixes to the x11 dynamic module.

The previous difficulty Ralph encountered appear to be due to gsparamx - it is listed as part of x11 (and therefore needed to be built with -fPIC) but it is also listed as part of psdf (and therefore affect windows build). If it is delisted as part of x11, it would be included as part of psdf anyway and its needed content be found, so not listing it as part of x11 would allow building the x11 module as dynamic without requiring changes to windows build.
Comment 12 Hin-Tak Leung 2010-07-27 12:03:17 UTC
Ralph's r8270 includes another file gdevemap for 'Provide a mapping between StandardEncoding and ISOLatin1Encoding' .

It is list as part of macos.dev (for mac builds), and mswindll2_ for windows builds.
It is a small file which consists of two arrays: 
const byte gs_map_std_to_iso[256], and byte gs_map_iso_to_std[256]. 

Only 3 files uses those - gdevmacxf.c, gdevmsxf.c , gdevxxf.c . They all need gs_map_std_to_iso[], but only gdevxxf needs gs_map_iso_to_std[] . Since gdevemap is small enough and has not been changed for the last 10 years and unlikely to change ever, to avoid changing windows/mac classic builds, it is probably appropriate for gdevxxf to have its own copy of those arrays and decouple the x11 device from depending on gdevemap .
Comment 13 Hin-Tak Leung 2010-07-27 12:21:51 UTC
Created attachment 6560 [details]
carios dynamic module patch

cairo dynamic module patch and another go at fixing problems with x11 dynamic module.

Not listing gsparamx (part of psdf and therefore almost always available) and gdevemap (use on mac and windows for xfont support; insert where it is needed) as x11 dependency avoid modifying non-unix builds.
Comment 14 Chris Liddell (chrisl) 2010-07-27 18:17:29 UTC
It is now our intention to remove the gdevcairo device from the Ghoscript build, either for the 9.0 release, or soon after.

If this poses a problem, register your protest here!
Comment 15 Hin-Tak Leung 2010-07-27 18:42:17 UTC
ghostscript still have a fair amount of problems with cairo generated pdf's. Beside the obvious ones, there are these bugs: 690504 691257 691289
http://bugs.ghostscript.com/show_bug.cgi?id=691131#c19
which seems to suggest they are directly attributed to cairo.

Having a way of driving cairo is possibly a way of making sure ghostscript can consume cairo-genetated pdf's, as a few big projects has adopted cairo as its output generator; besides google-chrome, there are language bindings for perl and python (and others) so many are using cairo as a quick way of supporting multiple output formats without writing an output module for each format.
Comment 16 Till Kamppeter 2010-07-27 18:51:28 UTC
Hin-Tak, the "cairo" output device is not for improving compatibility with Cairo-generated input files. The input files are only treated by the interpreters (PostScript, PDF) and this is independent of the output device. The "cairo" output device is for using Cairo to display the input file on the screen. So it is an alternative to the "x11" and "x11alpha" output devices. So it could be used to replace the rather broken "x11alpha", but disadvantage is that there are Linux distributions not shipping Cairo (AFAIK Kubuntu) and probably also the cairo output device does not allow searching and copying displayed text (please tell if it is the case or not).

So I am not much in favor of keeping the "cairo" output device. For PDF/PostScript viewers I suggest converting PostScript using "pdfwrite" and then displaying everything with Poppler (in the future perhaps with mupdf).
Comment 17 Hin-Tak Leung 2010-07-27 19:36:11 UTC
(In reply to comment #16)
> Hin-Tak, the "cairo" output device is not for improving compatibility with
> Cairo-generated input files. The input files are only treated by the
> interpreters (PostScript, PDF) and this is independent of the output device.
> The "cairo" output device is for using Cairo to display the input file on the
> screen. So it is an alternative to the "x11" and "x11alpha" output devices. So
> it could be used to replace the rather broken "x11alpha", ...

I am not aware of the ghostscript cairo device can be used for display, but 
"... -sDEVICE=cairo -o newfile.pdf ..." works as an alternative to pdfwrite, and I think the cairo device auto-sense output format by extension - just looked at the code - apparently it can be used as alternative to png* as well, beside svg.

It is a possible way of generating some pdf's which gs still seems to have problem consuming.
Comment 18 Till Kamppeter 2010-07-27 21:34:09 UTC
Hin-Tak, sorry, I never used the "cairo" output device and I always thought that it is an alternative screen displayer. So it really is a Cairo-based file converter producing the file types which Cairo can produce. But this also does not improve the probability that a Cairo-generated input file gets correctly rendered. It gives also an alternative to over shortcomings of other Ghostscript output devices, but it introduces also Cairo's problems, see for example the Ubuntu bug reports about printing problems with evince. evince uses Cairo not only for screen display but also for generating PostScript or PDF when sending the displayed file to the printer.
Comment 19 Chris Liddell (chrisl) 2010-07-29 16:08:06 UTC
I spent some time today looking into Hin-Tak's suggestion that devcairo might be a good way to produce a test suite of Cairo produced files which GS struggles with.

I'm not sure it is useful even in that regard. I ran about two thirds of our "comparefiles" suite, converting to PDF using devcairo and then ripping with GS. other than being slow and using more memory (unvoidable with cairo's contant use of pointless transparency constructs in the PDF output), all the files were fine in GS - the only problems were two crashes using devcairo to do the conversion.

To make it useful, in even the limited way suggested, I think would take some time, and I suspect (from a quick look through the cairo reference) need changes in cairo itself, as well as devcairo.

I thik it is really too incomplete, and too unlikely to ever get worked on, to warrant keeping it in the released code base.
Comment 20 Hin-Tak Leung 2010-07-29 16:33:50 UTC
Regardless of whether to disable/remove the cairo device, there are some separate issues with the modularization of the x11 device while I was looking at this, and if appropriate, they should be considered separately.
Comment 21 Till Kamppeter 2010-07-29 19:14:03 UTC
Hin-Tak, the separate issues on the X modularization we should not drop. Please open a new bug with the patch only for the X modularization fixes (and give a link here) or better commit the X modularization fixes directly, so that they make it into GS 9.00 and Ubuntu Maverick.

The cairo device can really be dropped, once Cairo is not a really good PostScript/PDF generator and second, no one complained about the cairo output device, so no one is using it.
Comment 22 Hin-Tak Leung 2010-07-30 01:02:13 UTC
(In reply to comment #21)
> Hin-Tak, the separate issues on the X modularization we should not drop. Please
> open a new bug with the patch only for the X modularization fixes (and give a
> link here) or better commit the X modularization fixes directly, so that they
> make it into GS 9.00 and Ubuntu Maverick.

The x11 dynamic issue are filed as bug 691510 .
Comment 23 Chris Liddell (chrisl) 2010-07-31 16:09:19 UTC
As of r11582 the devcairo device is removed.