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 http://superuser.com/questions/303727/free-linux-command-line-tool-to-convert-svg-to-pdf-and-or-some-commonly-used-bit inkscape file.pdf --export-plain-svg=file.svg http://inkscape.13.x6.nabble.com/convert-pdf-to-svg-from-command-line-td2883388.html 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). --refs-- http://roland65.free.fr/texmaths/index.html http://extensions.libreoffice.org/extension-center/texmaths-1 http://ooolatex.sourceforge.net/
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 Version: 4.3.1.2 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. --ref-- http://www.cityinthesky.co.uk/opensource/pdf2svg/
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: https://github.com/luser-dr00g/xpost
*** Bug 103674 has been marked as a duplicate of this bug. ***
(In reply to Tomaz Vajngerl from https://bugs.documentfoundation.org/show_bug.cgi?id=122436#c17 ) > I think we should start to look how to deprecate EPS support in LO. Best > would be to try to convert EPS graphic to PDF for existing LO documents, but > otherwise remove EPS graphic as an input filter for use in LO documents. > Export can still be there (for printing). > > EPS is not really even a graphic format but a Turing complete language, > which had some sense in the past to have that, but nobody writes complex > vector graphic as a program by hand today. So having a super complex > language to interpret as a input instead of declarative set of limited > instructions just doesn't make sense. > > As long as we have it in LO, the user will use it. Now that LO 7.0 is > getting near, it is a great opportunity to drop it. But can't the same be said for the XML holding SVG? Anyhow, provind folks a clean path to import their ps/eps/pdf to functional EMF/SVG vector graphics. If not popler/cairo then maybe pdfium/skia? Just bring it in with high fidelity with pushing it into BMP rasters. At that point we can drop the ps/eps/pdf from the archive and not have to worry about printing or round tripping, right?
(In reply to V Stuart Foote from comment #21) > Just bring it in with high fidelity with pushing it into BMP rasters. s/with pushing/without pushing And, kind of seems like eps/epsi died long ago--but many graphics programs still generate it for high fidelity vector graphics--and ghostscript as interpreter is not going away anytime soon. We just need a way to get it out of ps and over to SVG and/or EMF+ without losing vector resolution and good handling of text runs.
(In reply to V Stuart Foote from comment #21) > But can't the same be said for the XML holding SVG? Absolutely not. XML is a language to define a tree-like structure of elements and attributes. SVG just defines what those elements are. When you write a SVG you pretty much write it declarative. There are Turing complete languages written in XML - XLST for example, but that doesn't mean XML is. SVG would be similar only if combined with JavaScript. PDF compared to EPS dropped all the control structures so it pretty much was made into a declarative format. That's why there are PDF parsers around and it's not that hard to write one yourself. Not so for EPS - if you want to support it you pretty much must write a complete language interpreter or it just won't work. > If not popler/cairo then maybe pdfium/skia? > > Just bring it in with high fidelity with pushing it into BMP rasters. At > that point we can drop the ps/eps/pdf from the archive and not have to worry > about printing or round tripping, right? If we can convert EPS in documents to PDF and use pdfium for rendering, that would already solve the issue for us, but as I said I would drop EPS support as an input format as we really don't have it - not even now or in the past. The hacks like this in VCL are just slowing us down when we try to modernize it.
*** Bug 128269 has been marked as a duplicate of this bug. ***