Problem description: Steps to reproduce: 1. Insert an image in eps format 2. Export to PDF 3. Open PDF file Current behavior: Image does not get exported and no error message is given Expected behavior: Image should get exported but even more importantly, when something goes wrong, don't make the program pretend everything went fine. This can cause quite some headaches when giving a presentation. Add some checks in the code. Operating System: Linux (Other) Version: 4.0.2.2 release
Thanks for reporting! Is it possible to attach a sample eps image so we can try to reproduce this behavior? Thanks in advance, Joren
May be related to Bug 34836 (but is reported against Mac OSX). If this is a duplicate, we can mark that bug as 'platform all'. Kind regards, Joren
The problem is totally reproducible. You can find sample eps/odp/pdf files at this address: http://bit.ly/12sJy9t The problem seems related to other (maybe all) eps files as well. I am using LibreOffice 4.0.2-0ubuntu1 on Ubuntu Raring (13.04). Downgrading to 3.6.2~rc2-0ubuntu3 from Ubuntu Quantal fixes the problem (12.10).
Thanks for your additional information! Indeed, I can reproduce this behavior using Linux Mint 14 x64 with LibreOffice 4.0.3.2 When I Insert > Picture > From File... this in Impress, and export it as PDF, the image dissapears. When I do the same using Writer, the image is exported correctly. Tested using LibreOffice Version: 4.1.0.0.alpha0+ Build ID: 201f5fb6367a67cd39fa8e4396f5f86589db6be When I try to insert the eps file in Impress AND Writer I get this warning: Graphics filter not found
Regression. Bibisected: 9a5620ca6473969359f262802c76daf35cbcbb5d is the first bad commit commit 9a5620ca6473969359f262802c76daf35cbcbb5d Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Tue Dec 11 01:59:31 2012 +0000 source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc commit ae4e4a11d4300f7448cb6bd170fcb034542caddc Author: Rene Engelhard <rene@debian.org> AuthorDate: Tue Nov 6 21:24:32 2012 +0100 Commit: Rene Engelhard <rene@debian.org> CommitDate: Tue Nov 6 21:24:32 2012 +0100 typo... Change-Id: I2c7968194afbcf74967cd16c639dce7de858a513 :100644 100644 c09b92a8ddf24b8738a7cd3a695ae1e4482d354c 6b13afd13f023cedac65a896318de4aa55dead27 M autogen.log :100644 100644 bcee1e11bd693642ca5a6330175b58082e5dcdd0 54d2377f5b3afd6ed668b3e24cb877c289119ec5 M ccache.log :100644 100644 75677cef16786d2cc95c0d8f301482278ca055c3 d18a6ebcd3b8537c3dd3dbc16e862fb6370ecb8a M commitmsg :100644 100644 83b4ecc0ecb3e031c804d49f45f854e95d5cc961 d482c00e5fff6081c6b87b637fd9ffaf3e1e2c6c M dev-install.log :100644 100644 91437b9974ffada7e049273419bb8c66c91c0539 abf45ab9609c77a5ab952aa310eafe8c2ffaf85c M make.log :040000 040000 45c0bab8b669778ab523c8f65a25e8c9afde604a f4bfa15b2f72d3df5675b07bcf32254a819b9d19 M opt git bisect start # good: [50612eb408c515e3672952083b805be708d59c4a] root git bisect good 50612eb408c515e3672952083b805be708d59c4a # bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4 git bisect bad 5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a # good: [5478f58adef21d3378257c60396d29a8653bafd3] source-hash-c52ba433491afbca70aa1977a624c795bdd5b9ef git bisect good 5478f58adef21d3378257c60396d29a8653bafd3 # good: [2b0b6ee32c35c478fcde0ab1c70f2a3d2342cc21] source-hash-bed0447cefb949fc77cfde7543397d96590082ba git bisect good 2b0b6ee32c35c478fcde0ab1c70f2a3d2342cc21 # good: [114fd3b76bcba890e6d702d00cef910f1493c262] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902 git bisect good 114fd3b76bcba890e6d702d00cef910f1493c262 # bad: [47498a36f7af8f54e6e3dda89cd4708802a409e6] source-hash-19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7 git bisect bad 47498a36f7af8f54e6e3dda89cd4708802a409e6 # good: [f4e2d84db194943180f3e7ed4adce5f8e377d9bc] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10 git bisect good f4e2d84db194943180f3e7ed4adce5f8e377d9bc # bad: [fb4214f9d134b556582a4a5280e5458de5f8eebd] source-hash-683758efb22d08a4cf211a6d985148f513da2a90 git bisect bad fb4214f9d134b556582a4a5280e5458de5f8eebd # good: [e2e46267c18c2706de771a08472ebfce19f68520] source-hash-4316e643ef345b0f673b4a03a80a4b7cb3185588 git bisect good e2e46267c18c2706de771a08472ebfce19f68520 # bad: [9a5620ca6473969359f262802c76daf35cbcbb5d] source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc git bisect bad 9a5620ca6473969359f262802c76daf35cbcbb5d range: http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=4316e643ef345b0f673b4a03a80a4b7cb3185588..ae4e4a11d4300f7448cb6bd170fcb034542caddc
*** This bug has been marked as a duplicate of bug 34836 ***
Reopened since #34836 was closed and split into individual bugs. I bisected the issue to this commit: http://cgit.freedesktop.org/libreoffice/core/commit/?id=44cfc7cb6533d827fd2d6e586d92c61d7d7f7a70 : commit 44cfc7cb6533d827fd2d6e586d92c61d7d7f7a70 Author: Michael Meeks <michael.meeks@suse.com> Date: Tue Oct 9 12:22:23 2012 +0100 re-base on ALv2 code. Includes (at least) relevant parts of: [...] I reproduced the bug in AOO 3.4.1, which leads to the conclusion that the issue comes with the re-based code, and is not a side-effect of the re-base itself.
*** Bug 67632 has been marked as a duplicate of this bug. ***
*** Bug 67240 has been marked as a duplicate of this bug. ***
*** Bug 68403 has been marked as a duplicate of this bug. ***
adjust version according to comment #7
Can you please provide a test document so this can be tested on newer LO versions? Setting to NEEDINFO until more detail is provided. After providing the requested info, please reset this bug to UNCONFIRMED. Thanks :)
Since I don't see much hope this bug is going to get fixed or that eps images might ever be ever able to be used again in LibreOffice, here is a workaround. Convert your pdf (or eps) image to svg with the program pdf2svg (also epstopdf). Images in the svg format work just as well and LibreOffice seems to handle them just right.
Created attachment 89721 [details] Test file with embedded EPS image (and SVG for comparison)
OK, I have added several attachments which demonstrate the broken behavior of LO when Exporting As PDF with embedded EPS. Essentially, the image is not exported correctly (background is missing under the EPS image at top) and *in addition* the text in the file is completely missing. At least OpenOffice exports the text (though it also fails on the EPS background export). Note that the SVG rendering is also broken in LO, so the SVG approach suggested above is not really workable. LO-PDF-Bug.odt - LibreOffice document used for test LO-PDF-Bug.pdf - Output of LibreOffice "Export As PDF" LO-PDF-Bug-using-OOo.pdf - Output using OpenOffice on the same .odt file. This was all done on LibreOffice Version: 4.1.3.2 on Mavericks 10.9.0 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a (with pstoedit installed via MacPorts and available on the path).
Created attachment 89722 [details] Output of Export As PDF produced by LO
Created attachment 89723 [details] Output of Export As PDF using OpenOffice, for comparison
set status to NEW because of previous confirmations.
I will be out of the office until Monday, January 6th, 2014. If you have an emergency please send and email to rt-skokie.
Adding this to MAB 4.2 as mis-handling of EPS originated images should be linked with bug 62038 (EPS based imaged missing in Impress Slideshow mode) and bug 62051 (EPS rendering in Windows missing).
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4d88c6dee6d57fa9c366b67624842aefa429f527 Related: fdo#64161 pstoedit not writing file until its closed The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 98174 [details] the extracted eps
I believe I've fixed the *general* case here with http://cgit.freedesktop.org/libreoffice/core/commit/?id=3db00c554b38ee6c1b6e969768da53db4dc2f92a and http://cgit.freedesktop.org/libreoffice/core/commit/?id=4d88c6dee6d57fa9c366b67624842aefa429f527 But in the specific example here it turns out that pstoedit isn't rendering the eps to emf correctly. i.e. pstoedit -f emf:-OO 200000020000010F000000736BBF1512.eps output.emf is how we execute pstoedit in order to create the preview and unfortunately that emf is blank for that image. So the general case is fixed, but the specific example here falls into a pstoedit (3.62-3.fc20) problem/bug. Forwarded that eps to Wolfgang as per http://www.helga-glunz.homepage.t-online.de/pstoedit/pstoedit.htm
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f793a5a2847e5fe03ccacf7127c153a76863d468&h=libreoffice-4-2 Related: fdo#64161 pstoedit not writing file until its closed It will be available in LibreOffice 4.2.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 75216 has been marked as a duplicate of this bug. ***
*** Bug 77339 has been marked as a duplicate of this bug. ***
Confirming fixed on Windows 7 sp1, 64-bit Version: 4.3.0.0.alpha1+ Build ID: 0b03f7ed575838f90e6b1ebec3538a3a214f81fb TinderBox: Win-x86@39, Branch:master, Time: 2014-04-30_01:30:46 with Caolan's commits on master. However, pstoedit (for vector formatted previews), GhostScript, and ImageMagick must be correctly configured and available on system path.
Created attachment 98208 [details] Export to PDF of test ODP impress with inserted EPS and EMF
Created attachment 98210 [details] test ODP impress with inserted EPS and EMF
Created attachment 98213 [details] rif on attachement 98174, parsed through Inkscape
Created attachment 98216 [details] draw rendering of EPS and EMF as fixed A Draw rif on @etiffany test document, top is default LODev 430alpha1+ raster preview of provided EPS. Middle is that same EPS parsed through Inkscape as EMF (note vector preview), bottom is the same EPS parsed with Inskscape back to "cleaner" EPS retains color but is also a raster preview. All three render as vector based in PDF, to follow. So issue is resolved, but quality of "preview" handling of EPS may depend on structure of the EPS. Works well on Windows if flushing through Inkscape. Need to verify that all is good with OS X.
Created attachment 98217 [details] PDF export from draw rendering of EPS and EMF as fixed
Thanks! I works for me (Ubuntu 14.04 64 bits) with last fix, it wasn't working with writer 4.2.3.3. I have a lot of EPS images in my documents, just one example of pdf generated with last fix, writer Version: 4.2.5.0.0+ Build ID: 59906c3d54e6541185f4bf85b1d1c70530198059 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-2, Time: 2014-04-30_08:37:13 I could share .odt for testing purposes as EPS images and document have cc-by license by me http://www.fiquipedia.es/home/recursos/recursospau/ficherospaufisicaporbloques/F5.1-PAU-LuzOpticaFisica-soluc.pdf?attredirects=0 Just a comment: when installing last daily build I used sudo dpkg -i --force-depends-version *.deb I need to use force option because of (I guess) wrong dependencies: it ask for <= 4.2.5.0.0 and the package is >, 4.2.5.0.0-1. ? Output in install (spanish) "Configurando libreofficedev4.2-writer (4.2.5.0.0-1) ... dpkg: lodevbasis4.2-base: problemas de dependencias, pero se configurará de todas formas tal y como se solicitó: lodevbasis4.2-base depende de lodevbasis4.2-core01 (<= 4.2.5.0.0); sin embargo: La versión de `lodevbasis4.2-core01' en el sistema es 4.2.5.0.0-1."
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1a428ed5670e0257b21c04590ce95b86b2896ee4 Related: fdo#64161 ask pstoedit to mark out the bounding box The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
It works (pdf ok) for me with last nightly build (Version: 4.2.5.0.0+ Build ID: da62ab5783e548c5785b3950c03d078b1f3e849d TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-2, Time: 2014-05-16_08:11:51) and test doc from comment 34 After reading some comments I checked I do not have installed pstoedit when doing previous tests, and anyway is working with last nightly build Installing pstoedit: version 3.62 / DLL interface 108 (built: Dec 22 2013 - release build - g++ 4.8.2 - 64-bit) give the same not working result with LO 4.2.3.3 (Versión: 4.2.3.3 Id. de compilación: 420m0(Build:3))
Sorry, in previous comment I wanted to say "test doc from comment 14", not 34
Dear all, unfortunately I have to report that this bug is not entirely fixed. I cross-checked a long document with multiple EPS files and I found two regressions over LO 4.1.x that are still related to this bug. 1st problem: If an EPS graphic exceeds 100% (relative to text width), it is lost in PDF export. This is an regression over LO 4.1.x where this was no problem. Attached is a sample .odt and .pdf file showing on the first page a EPS graphic with 101% width which is entirely lost in the PDF export. The EPS grpahic on the second page (100% width) has no problem. 2nd problem: Severe regression of rendering quality of EPS graphics in 4.2.5 over 4.1.x. For this I opened a new bug entry: bug 81592 LibreOffice Version: 4.2.5.2 Build ID: 61cb170a04bb1f12e77c884eab9192be736ec5f5 Ubuntu 14.04 Gnome3 64-bit
Created attachment 103178 [details] EPS-in-Writer-document-does-not-get-exported-in-L425.pdf
Created attachment 103179 [details] EPS-in-Writer-document-does-not-get-exported-in-L425.odt
@Gerry. tnanks. good catch!!! I thinks is better to leave this closed and open 2 separate follow-up bugs about the residual issues. I see that you already did for the 2nd problem which is good but I think it's better to start a clean new (easier to read) report about the 100% corner case. you don't need to upload again the files, just copy and paste attachment numbers in the new report description and put this bug number under "see also" will you do that?
@tommy27: Done. I created bug 81598
thanks Gerry for your understanding. reverting status to FIXED. let's continue discussion about residual issues on those new reports.