Bug 62051 - UX Impress, Draw and Writer do not render inserted EPS as viewable element on Windows
Summary: UX Impress, Draw and Writer do not render inserted EPS as viewable element on...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: Other Windows (All)
: high critical
Assignee: Not Assigned
: 125979 (view as bug list)
Depends on:
Blocks: Images-EPS mab4.2
  Show dependency treegraph
Reported: 2013-03-09 09:18 UTC by Rainer Bielefeld Retired
Modified: 2019-10-13 17:18 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

This .eps works fine (140.21 KB, application/postscript)
2013-03-09 09:18 UTC, Rainer Bielefeld Retired
screenshot in 4.0.1 on RFR17 64bit (227.49 KB, image/png)
2013-03-11 10:33 UTC, sasha.libreoffice
another screenshot in 4.0.1 on RFR17 64bit (196.89 KB, image/png)
2013-03-11 10:38 UTC, sasha.libreoffice
test ODP impress with inserted EPS and EMF (120.15 KB, application/vnd.oasis.opendocument.presentation)
2014-04-30 05:36 UTC, V Stuart Foote
Export to PDF of test ODP impress with inserted EPS and EMF (110.96 KB, application/pdf)
2014-04-30 05:39 UTC, V Stuart Foote

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2013-03-09 09:18:00 UTC
Created attachment 76209 [details]
This .eps works fine

I found this during my research for "Bug 47458 - [Task] EPS graphics not displayed properly"

Steps how to reproduce with  "LibreOffice " German UI/ German Locale [Build-ID: 5b93205] {pull date 2013-01-18} on German WIN7 Home Premium (64bit)

1. Open presentation in  Attachment 70774 [details] for Bug 47458 from
   LibO Start Center File menu
   Expected: Simple picture with text "Hello World" in it shown
   Actual: only brown rectangle around an empty transparent area shown as 
           placeholder, no placeholder text shown in it.

More test results concerning separate "An_even_simpler_EPS.eps" in test kit:
- Same view when 
  -- fileopen with Draw
  -- Menu 'Insert -> Picture from File -  An_even_simpler_EPS.eps' in Draw, Calc
     and Impress 
- additional Placeholder info (Creator, Creation Date, Language Level, Title)
  shown whne inserted into Writer document

Additional Info:
Already reproducible with LibO 3.3.3 and AOOo 3.4.0, so inherited from OOo
Still the same in Master. 
There are smaller differences, but I never see a picture back until OOo 1.1.5

Most .eps sample drawings seem to be affected, but not all 

Can you confirm (exactly!) this behavior with other OS for LibO 3.6 or later?
Comment 1 sasha.libreoffice 2013-03-11 10:33:35 UTC
Created attachment 76327 [details]
screenshot in 4.0.1 on RFR17  64bit
Comment 2 sasha.libreoffice 2013-03-11 10:38:31 UTC
Created attachment 76328 [details]
another screenshot in 4.0.1 on RFR17  64bit
Comment 3 ign_christian 2013-07-04 04:41:16 UTC
Confirm reproducible on LO (Win7 32bit), that eps image in odp file not shown on edit mode. Eps file also show nothing on Draw.

After some searching on another bugs, seems that only Windows system can't show that image on edit mode.
Comment 4 V Stuart Foote 2014-04-26 16:03:14 UTC
Adding this to MAB 4.2 as issues here on Windows, and for related bug 62038, and earlier bug 47458 suggest something is seriously deficient in LO filter handling of EPS.

Rainer's attachment 76209 [details] contains an embedded preview, that bitmap rendering is what gets inserted (at a very low resolution) into a writer, calc or impress document.

If the sample .eps file is edited to remove the %%BeginPreview -> %%EndPreview stanza's the sample .eps reverts to rendering as only a placeholder box. Builds through the release show some file metadata.  But with release onward it is just an empty placeholder (so suspect that reflects changes of commit "EPS import: convert to BMP instead of PNG" ( http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-0-0&id=f3123d396c8f7f175551a9bab8bc232efe602083 )

tested on Windows 7 sp1, 64-bit with

Version (Build ID: 5b93205)

through a recent build of master.

Build ID: 087a79db1272858f107656c5ca3c6efb45680986
TinderBox: Win-x86@39, Branch:master, Time: 2014-04-16_01:43:37
Comment 5 V Stuart Foote 2014-04-26 20:34:30 UTC
Posted this to a Dev list thread, repeating here...

Was looking in OpenGrok at ieps.cxx
<http://opengrok.libreoffice.org/xref/core/filter/source/graphicfilter/ieps/ieps.cxx>  Linux seems to use the GhostScript -- gs command that is commonly bundled. But Windows seems to require use of ImageMgaick convert command.  That is not normally a program a Windows user would install!

I installed an ImageMagick binary (32-bit static
ImageMagick-6.8.9-0-Q16-x86-static.exe) from http://www.imagemagick.org/script/binary-releases.php  and all versions of LibreOffice through 4.1.x now render a viable image of the EPS.

Can find nothing noting a requirement for ImageMagick as a install
dependency, should ImageMagick be bundled if EPS rendering is depending on

Also, for releases from on, the insert image from EPS results
in a fully black fill for the image preview--suspect that was from the commit at noted above that moves from PNG to BMP rendering and may need some additional adjustment.
Comment 6 V Stuart Foote 2014-04-26 21:48:41 UTC
Some bread crumbs from the OOo days in this issue: https://issues.apache.org/ooo/show_bug.cgi?id=72096

Caolan?  Any recollection of how the ImageMagick convert.exe and dll's were to be made available to Windows users?
Comment 7 V Stuart Foote 2014-04-27 03:19:30 UTC
Hey, so this gets better. The commit noted at comment 4 shifts rendering to BMP, but it does not fully implement it if using ImageMagick convert. It does seem to have full conversion on Windows using GhostScript.

So, on a hunch I downloaded and installed the GNU Affero GPL licensed Ghostscript 9.14 for Windows (32 bit) from http://www.ghostscript.com/download/gsdnld.html

I'm on Windows 7 sp1, 64-bit so to force use of the 32-bit app---gswin32c.exe---I added the directory to the PATH environment-- C:\Program Files (x86)\gs\gs9.14\bin

Now with both ImageMagick and GhostScript inatalled--Insert ->Picture ->from File for EPS into Writer, Impress and Draw is functional through current builds of 4.3.0 Alpha1

However, issues of bug 62038 and non-rendering during Slideshow mode of Impress are NOT resolved. Nor are the issues of bug 47458 in exporting to PDF and including the EPS based image in the export or print.
Comment 8 V Stuart Foote 2014-04-27 17:16:49 UTC
Bug 64161 is the better issue regards export to PDF and printing of EPS based images.

Also for Windows use, until bug 67464 provides enhancement of native handling of EPS, there are three "helper" programs that are currently called by the ieps.cxx import routines.

GhostScript -- gswin32c.exe  ( http://www.ghostscript.com/download/gsdnld.html )
ImageMagick -- convert.exe  ( http://www.imagemagick.org/script/binary-releases.php#windows )
pstoedit -- pstoedit.exe ( http://sourceforge.net/projects/pstoedit/files/pstoedit/ )

Beyond regaining some capability to work with EPS on Windows installs of LibreOffice, not clear which of them must be present for correct LO function. Or if they all must be installed. Or if there are advantages of one over the others if choice is possible.
Comment 9 Caolán McNamara 2014-04-29 11:18:34 UTC
This has now gotten a bit complicated. So lets try and simplify this now.

We can't render eps ourself natively, lets leave bug 67464 for that specific long-term tricky problem and focus on the remaining problems.

a) If an eps already includes a preview image, we should be able to show that on screen and when printed to pdf
b) If an eps does not include a preview image, then we try to launch pstoedit, then gs, and then convert to create one. If that succeeds we should be able to show that on screen and when printed to pdf. It is exceedingly unlikely to have those installed on windows I appreciate.
c) If none of that works then we generate a redbox with some metadata in it like the author and creator if that info is available. That should show on screen and when printed to pdf.

I've made a few fixes now in master http://cgit.freedesktop.org/libreoffice/core/commit/?id=3db00c554b38ee6c1b6e969768da53db4dc2f92a and http://cgit.freedesktop.org/libreoffice/core/commit/?id=4d88c6dee6d57fa9c366b67624842aefa429f527

I would appreciate (with tomorrows daily for example) if you could test that if with the above fixes on windows that a-c now happen there as expected, then I would consider this fixed and closable.
Comment 10 V Stuart Foote 2014-04-30 05:36:28 UTC
Created attachment 98204 [details]
test ODP impress with inserted EPS and EMF

Caolan, *,
(In reply to comment #9)
> I would appreciate (with tomorrows daily for example) if you could test that
> if with the above fixes on windows that a-c now happen there as expected,
> then I would consider this fixed and closable.

On Windows 7 sp1, 64-bit with
Build ID: 0b03f7ed575838f90e6b1ebec3538a3a214f81fb
TinderBox: Win-x86@39, Branch:master, Time: 2014-04-30_01:30:46

Working with pstoedit (win32) v3.62 installed.

GhostScript 9.14 (gswin32c) and Imagemagick 6.8.9 (convert) also present on system path.

Attaching a test .ODP file and resulting .PDF export.  The pstoedit preview rendering is visible in impress slides on edit mode and in slideshow. The EPS is being rendered into PDF as vector image. Samples of EMF conversion of the EPS from Inkscape show the much cleaner handling of text including its text to paths function.  But the EMF conversion is not perfect--note the missing smile on the smily face.

Still need to repeat with pstoedit removed to verify correct bitmapped affects, but comfortable calling this resolved fixed.
Comment 11 V Stuart Foote 2014-04-30 05:39:52 UTC
Created attachment 98205 [details]
Export to PDF of test ODP impress with inserted EPS and EMF

The ODP as exported into PDF from Impress.  In addition to valid PDF export, all the slides now render in Slide show mode with commits to this build of master.
Comment 12 V Stuart Foote 2014-04-30 05:45:16 UTC
Setting resolved fixed but noting that some mix the helper files noted in comment 8 are required to work with encapsulated postscript files on Windows.

But also, that Inkscape conversion of EPS to EMF is already natively supported in LibreOffice and that external conversion is a viable work around for handling EPS formatted content as full resolution vector data.
Comment 13 V Stuart Foote 2019-10-13 17:18:33 UTC
*** Bug 125979 has been marked as a duplicate of this bug. ***