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 3.6.5.2 " 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 @all: Can you confirm (exactly!) this behavior with other OS for LibO 3.6 or later?
Created attachment 76327 [details] screenshot in 4.0.1 on RFR17 64bit
Created attachment 76328 [details] another screenshot in 4.0.1 on RFR17 64bit
Confirm reproducible on LO 4.0.4.2 (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.
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 4.1.6.2 release show some file metadata. But with 4.2.0.4 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 3.6.5.2 (Build ID: 5b93205) through a recent build of master. Version: 4.3.0.0.alpha0+ Build ID: 087a79db1272858f107656c5ca3c6efb45680986 TinderBox: Win-x86@39, Branch:master, Time: 2014-04-16_01:43:37
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 it? Also, for releases from 4.2.0.4 on, the insert image from EPS results in a fully black fill for the image preview--suspect that was from the commit at 4.2.0.0 noted above that moves from PNG to BMP rendering and may need some additional adjustment.
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?
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.
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.
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 caolanm->vstuart: 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.
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 Version: 4.3.0.0.alpha1+ 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.
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.
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.
*** Bug 125979 has been marked as a duplicate of this bug. ***