(Using libgs from: ghostscript-9.05-1.fc17.x86_64.rpm ) I see from Bug #690009 that DEVICE=cairo support has been removed from libgs ? This is a disappointing after I wrote a plugin for graphviz < http://www.graphviz.org/ > that would load arbitrary postscript images and render them as node labels in a graph and render the composite graph to any output format supported by cairo. Any chances of reinstating the device? Or do you suggest some alternate method of importing postscript to a cairo surface? In particular, in a way that retains the vector format until and unless the final output is a bitmap. Is the cairo device for gs something I could carry in graphviz code? Does libgs accept runtime plugin devices?
(In reply to comment #0) > Is the cairo device for gs something I could carry in graphviz code? Does > libgs accept runtime plugin devices? The cairo device can probably be adapted to use the opvp interface (which is the closest thing to a runtime plugin). OTOH, it probably isn't too difficult to build a patched version of gs with the cairo device added back in, for yourself.
> The cairo device can probably be adapted to use the opvp interface (which is > the closest thing to a runtime plugin). I'll investigate, thanks. Is DEVICE=opvp in 9.05 ? Fully documented? > OTOH, it probably isn't too difficult to build a patched version of gs with the > cairo device added back in, for yourself. Doesn't help. Its not for me alone, its for graphviz users on regular Linux distributions.
(In reply to comment #2) > > The cairo device can probably be adapted to use the opvp interface (which is > > the closest thing to a runtime plugin). > > I'll investigate, thanks. Is DEVICE=opvp in 9.05 ? Fully documented? Yes, it is included; No, not much documentation is bundled; The primary site for opvp is http://opfc.sourceforge.jp/, there is also, on a quick search, 3rd-party (or rather, "4th-party") resources at https://github.com/naruoga/OPVP-RPDL . It would help if you can read/write Japanese since the opvp mailing lists are primarily Japanese-based... adding Till to CC who might want to help/advise...
Thanks. Unfortunately I have no Japanese skills, although I've visited a couple of times and loved what I saw. I've found opvp.h in the ghostscript sources and, as I understand it from a quick glance, I would provide the opvp device with a set of functions to handle primitive drawing operations... ... I'm guessing the cairo device must have implemented some very similar functions ? Would it be possible to get, or get a pointer to, the cairo device subtree at the time of its removal?
Created attachment 8937 [details] The commit which removes the cairo device. The commit which remove the cairo device was: commit b0bb40ca5fce7444b0046818144d2e85dac3dcf7 Author: Chris Liddell <chris.liddell@artifex.com> Date: Sat Jul 31 16:07:37 2010 +0000 Remove the "dead" devcairo device. Generated with: git format-patch -1 b0bb40ca5fce7444b0046818144d2e85dac3dcf7
(In reply to comment #4) > Would it be possible to get, or get a pointer to, the cairo device subtree at > the time of its removal? You can tried applying the patch in reverse (attached to the bug report). Likely it won't apply cleanly since a few things have changed, but here is a start. If you are happy enough with using git, here is the command which would extract a source tar ball just before the removal of the cairo device (untested, but should work...): git archive --prefix=ghostcript_cairo/ \ b0bb40ca5fce7444b0046818144d2e85dac3dcf7^:gs/ > tarball.tar OTOH, if you are reading this on bugzilla, clicking on e7b50b898b454596562c8471778a90f0d9526b39 should go to the parent commit of b0bb40ca5fce7444b0046818144d2e85dac3dcf7 (ie. just before removal...), and you can click on "tree", then "snapshot" to get at a tar ball, which is probably easier.
The web-snapshot method will give you a larger tarball (including the rest of ghostpdl), and you would be only interested in the "gs" sub-directory in that. I am sure you will figure out when you see it.
Another request. Can Someone (Till?) point me to example code that uses the opvp device? And a concern... if I can use code from this gdevcairo.c ... who should I work Copyright/Licensing issues with? I'll be wanting the new code to go out under the Eclipse Public License, like the rest of graphviz. Currently it has a header that indicates Artiflex Software as the licensor.
The cairo device was little more than a proof of concept, and was incomplete and buggy, and no one had shown any interest in developing it further, hence its removal. I would suggest that a more complete, more reliable solution would be to use Ghostscript to convert the PS to PDF, and then import the PDF into cairo using, I guess, the poppler front end. Alternatively, if someone would like to volunteer to work on/maintain the cairo device, there is no reason we can't reinstate it - we just didn't like having unmaintained code with known problems in the distribution.
Chris, thanks, yes, I was looking at poppler last night and I think I will add PDF importer to graphviz, based on poppler, independent of any further progress on DEVICE=cairo or alternative for direct PS import to graphviz. As for the cairo device, well, it was working for me and I have existing code that uses it, so if you'd be willing to reinstate, perhaps I could take on some maintenance responsibility for it. The graphviz usage is fairly simplistic, so I'm not likely to catch many problems there. Is there an existing set of bug reports I should be aware of? Going down the DEVICE=opvp route to cairo might be plausible, but it looks like it might be a non-trivial amount of coding.
I don't believe we had a bug list for it. A while back we started doing regular testing of all the built in devices. We found quite a number of our QA tests crashed with the cairo device, and since it wasn't one of our "core" devices, nor did it have a maintainer, we opted to remove it. The only slight complication is that a number of our test files are either closed license test suite files, or confidential files from commercial or open source users, so if you do want to volunteer to work on it, we'd probably need to work out some non-disclosure agreement. Note that another complaint devcairo's removal was to address was from package maintainers, because including devcairo added a dependency on X for the Ghostscript "core" which is a problem for distributions that have a gui-less "server" edition.