Bug 690009

Small correction: I mean to move the "cairo" output device into the X output
device module or into its own module, not libcairo.

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.

Till: could you provide a patch for this?

No, I do not have any patch. In the Ubuntu packages I have simply disabled the Cairo output device ("./configure ... --disable-cairo ...").

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.

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.

re-assign to reporter to test patch. Patch to follow.

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).

*** Bug 691450 has been marked as a duplicate of this bug. ***

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.

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.

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 .

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.

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!

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.

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).

(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.

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.

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.

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.

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.

(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 .

As of r11582 the devcairo device is removed.