Users want to embed EPS' however we have no renderer that can handle these built-in; this sometimes causes problems as/when the hacky platform tools we spawn to try to make that work are moved around / not installed. cf bug#34836
It'd be lovely to have a (simple/minimal) EPS -> drawinglayer converter I guess.
I have searched pretty extensively for alternative EPS renderers but Ghostscript seems to be the only which is open source. Since Ghostscript is GPL (latest relese AGPL) only, it's not possible to link to it as a library unless LibreOffice changes its license.
I think the only solution is to bundle Ghostscript with LibreOffice and continue to spawn up a process when EPS rendering is needed.
Sure - or to start our own, small/simple PS renderer - and hope that we can cover some reasonable subset of the PS that people actually use these days without being perfect it could potentially be rather useful. But - as you say, this is rather a research project :-)
If anyone wants to continue on that route, the closest thing I found was this ongoing project to develop a PostScript level 2 interpreter: https://code.google.com/p/xpost/
Would it be easier to just convert it to another vector image like SVG?
inkscape can open EPS and convert it to SVG. We could borrow some code if license problem could be addressed. inkscape is GPLv2 and LO is LGPLv3.
I have just checked and SVG does not render properly in writer, neither in screen nor when exporting to PDF. If this is the way to go (I mean, converting to SVG and then rendering) it means two problems must be solved. It seems there is some literature on eps2svg, and inskcape imports correctly (ie: converts to SVG) although some human interaction is requested.
Definitely, SVG should be 100% correct. If it fails, it is a bug.
I did not notice problems with SVG import in my limited use cases.
About the "some human interaction", it is not necessary in order to convert eps to svg using inkscape. I has a commandline interface:
inkscape --without-gui --export-pdf="$(basename $i .svg).pdf" $i
inkscape file.pdf --export-plain-svg=file.svg
The ideal solution should be to use some kind of library. Anyway, conversion from EPS to SVG would allow libreoffice draw to modify the imported figure. Much better than current "convert to image using ghostscript".
Inkscape imports EPS files by executing pstoedit which in turn executes Ghostscript to interpret the EPS file. So same licensing problem with the interpreter.
I guess it's a bit premature to go and find code that's reusable to create the output format (SVG or otherwise) when there is no solution in sight for a built-in EPS interpreter.
A bit off topic: I've committed some draft code in Gerrit that builds the Ghostscript executable as part of LibreOffice.
Stumbled across this in looking at issue on Windows (bug 62051 - on MAB 4.2) where ImageMagick, GhostScript or pstoedit would almost never make it onto a users system. Yet the EPS importer ieps.cxx ( http://opengrok.libreoffice.org/xref/core/filter/source/graphicfilter/ieps/ieps.cxx ) seems to have implemented those.
With Impress in Slideshow mode not rendering EPS (bug 62038 - on MAB 4.2), and issues in Writer, Draw and Impress now dropping EPS based images during an Export to PDF ( bug 64161 - added to MAB 4.2) need to do better in handling of EPS both on import and when exporting.
To handle EPS, working internally with SVG as an alternative to pstoedit handling as EMF/WMF, would Martin Gieseking's dvisvgm project code (GPLv3 at http://dvisvgm.sourceforge.net/ )from the TeX device independent file format world (but still ghostscript bound) be functional?
It should render the EPS to SVG 1.1 with good fidelity, and then allow image manipulation as SVG without too much additional refactoring, making use of SVG's preview rendering and existing export filter handling for SVG.
Much of this is already being done for LibreOffice with Roland Baudin's TexMaths extension (derived from Geoffroy Piroux's ooolatex) with cross platform implementation--but depends on a LaTex helper--MikTek, TeXlive, MacTex--for Windows, Linux or OSX respective. Actually itself a good candidate for rework of the Maths core to implement LaTex (but that is a different issue).
Created attachment 105488 [details]
example ODT with EPS and a converted SVG
To show the current state of things--attached are an EPS file, logo for the xpost project (comment 3) and an writer file from 4.3.1 with that logo externally converted to SVG (in Inkscape 0.48.5 r10040 on Windows), and the EPS file rendered internally with pstoedit & ghostscript. And also the export of that writer document to PDF.
Note that the pstoedit rendering of the EPS is now horrible and that it does not improve when exported to PDF. Circles are line segments and corners are not mitered.
Working on Windows 7 sp1, 64-bit en-US with
Build ID: 958349dc3b25111dbca392fbc281a05559ef6848
pstoedit v3.62 - dll 108, Apr 28 2013
gswin32 9.14 - 2014-03-26
Created attachment 105489 [details]
xpost project logo example in EPS
The xpost project logo in EPS
Created attachment 105490 [details]
the same xpost project logo converted to SVG and in Inkscape
Created attachment 105491 [details]
export of example ODT to PDF
> handling as EMF/WMF, would Martin Gieseking's dvisvgm project code (GPLv3 at
> http://dvisvgm.sourceforge.net/ )from the TeX device independent file format
> world (but still ghostscript bound) be functional?
Xpost has a number of licensing advantages; the alternative - having to
have another out-of-process converter that is shipped only in some
configurations is really not ideal IMHO no matter how nice the fidelity.
(In reply to comment #14)
> Xpost has a number of licensing advantages; the alternative - having to
> have another out-of-process converter that is shipped only in some
> configurations is really not ideal IMHO no matter how nice the fidelity.
Didn't mean to suggest that we had to go with xpost, ghostscript is very much a functional resource, xpost is appealing as an alternative, especially if it could be built and bundled for all OSs. The project logo simply made a good EPS example.
If filtering EPS to convert it to SVG--the dvisvgm utility does it in one step, but has several dependencies as noted.
An alternative, and perhaps more appealing choice would be to use the ghostscript provided tool "ps2pdf -dEPSCrop" command to take each EPS to PDF, and then use a poppler and cairo wrapper to move from PDF to SVG (or other format).
Dave Barton's pdf2svg is a poppler & cairo based wrapper to do that conversion. I've used it a bit, and it is much cleaner than passing PDF (or EPS) through inkscape.
Was poking at a Windows build of poppler and find that for handling an EPS conversion to SVG the combination of Ghostscript's "ps2pdf" utility:
ps2pdf -dEPSCrop in.eps out.pdf
and Poppler's (from poppler-utils) "pdftocairo" utility:
pdftocairo -svg out.pdf out.svg
produces a VERY clean rendering of the EPS as SVG at a default 150dpi vector/pixel resolution, that can be bumped obscenely high with a -r resolution switch.
Looking at http://opengrok.libreoffice.org/xref/core/external/poppler/ExternalProject_poppler.mk we don't seem to build a lot of poppler currently for handling PDF.
But crazy question, could we do more with poppler to be able to handle EPS--could we build enough crossplatform to distribute the pdftocairo filter and solve the built-in EPS rendering?
Such that we could use quality SVG to replace EPS when adding to an open document? In a sense to never have to render the EPS onto the canvas. I would expect SVG previews would be more appealing than BMP (or WMF/EMF) previews of EPS we get now. Would have to decide about keeping the original EPS in the ODF archive or just keeping the SVG conversion.
We'd still require system ghostscript (unless Björgvin work as in comment 7 comes to fruition, or even incorporating the xpost project) but system ghostscript is already the state of things.
Anyhow just a thought.
I'm a sad about the truck-load of evil hacks a) currently in the code and b) proposed generally ;-) lots of things are do-able, but I suspect we only create deeper holes to fill-in later.
For myself I'd love to see a single, solid approach implemented (such as xpost) that we can be proud of & really support. The difficult part is the ps2pdf piece in the suggested command-line here; when it is rendered, it's easy enough to handle I think.
Unfortunately xpost seems to have stalled--or remains caught in the Google project hosting shutdown, and hasn't landed anywhere I can find.
Hence my thought that we'll be dealing with ghostscript going forward.
Otherwise Michael S. and Björn M. suggest handling EPS as a fully implemented extension (bundling all needed components) in comments over on bug 67465.
(In reply to V Stuart Foote from comment #18)
> Unfortunately xpost seems to have stalled--or remains caught in the Google
> project hosting shutdown, and hasn't landed anywhere I can find.
A simple google search shows it's now hosted on github:
*** Bug 103674 has been marked as a duplicate of this bug. ***