Bug 64161 - PDF: EPS images don't get exported when writing a PDF file
Summary: PDF: EPS images don't get exported when writing a PDF file
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: Other All
: high critical
Assignee: Not Assigned
URL:
Whiteboard: BSA bibisected40 target:4.3.0 target:...
Keywords: regression
: 67632 68403 75216 77339 (view as bug list)
Depends on: 62038
Blocks: Images-EPS mab4.2
  Show dependency treegraph
 
Reported: 2013-05-02 16:59 UTC by freeseek
Modified: 2017-10-22 08:01 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
Test file with embedded EPS image (and SVG for comparison) (59.11 KB, application/vnd.oasis.opendocument.text)
2013-11-24 21:08 UTC, etiffany
Details
Output of Export As PDF produced by LO (22.04 KB, application/pdf)
2013-11-24 21:13 UTC, etiffany
Details
Output of Export As PDF using OpenOffice, for comparison (60.13 KB, application/pdf)
2013-11-24 21:13 UTC, etiffany
Details
the extracted eps (36.25 KB, image/x-eps)
2014-04-29 10:45 UTC, Caolán McNamara
Details
Export to PDF of test ODP impress with inserted EPS and EMF (110.96 KB, application/pdf)
2014-04-30 06:13 UTC, V Stuart Foote
Details
test ODP impress with inserted EPS and EMF (120.15 KB, application/vnd.oasis.opendocument.presentation)
2014-04-30 06:14 UTC, V Stuart Foote
Details
rif on attachement 98174, parsed through Inkscape (34.06 KB, image/x-eps)
2014-04-30 07:12 UTC, V Stuart Foote
Details
draw rendering of EPS and EMF as fixed (71.17 KB, application/vnd.oasis.opendocument.graphics)
2014-04-30 07:22 UTC, V Stuart Foote
Details
PDF export from draw rendering of EPS and EMF as fixed (46.28 KB, application/pdf)
2014-04-30 07:23 UTC, V Stuart Foote
Details
EPS-in-Writer-document-does-not-get-exported-in-L425.pdf (92.76 KB, application/pdf)
2014-07-21 09:31 UTC, Gerry
Details
EPS-in-Writer-document-does-not-get-exported-in-L425.odt (41.30 KB, application/vnd.oasis.opendocument.text)
2014-07-21 09:32 UTC, Gerry
Details

Note You need to log in before you can comment on or make changes to this bug.
Description freeseek 2013-05-02 16:59:59 UTC
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
Comment 1 Jorendc 2013-05-02 18:30:25 UTC
Thanks for reporting!

Is it possible to attach a sample eps image so we can try to reproduce this behavior?

Thanks in advance,
Joren
Comment 2 Jorendc 2013-05-02 18:32:48 UTC
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
Comment 3 freeseek 2013-05-02 19:09:11 UTC
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).
Comment 4 Jorendc 2013-05-02 20:07:07 UTC
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
Comment 5 Jorendc 2013-05-02 20:42:38 UTC
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
Comment 6 Julien Nabet 2013-05-17 18:57:27 UTC

*** This bug has been marked as a duplicate of bug 34836 ***
Comment 7 Björgvin Ragnarsson 2013-08-01 04:08:22 UTC
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.
Comment 8 Thomas van der Meulen [retired] 2013-08-01 17:34:35 UTC
*** Bug 67632 has been marked as a duplicate of this bug. ***
Comment 9 Björgvin Ragnarsson 2013-08-02 15:11:04 UTC
*** Bug 67240 has been marked as a duplicate of this bug. ***
Comment 10 Björgvin Ragnarsson 2013-08-26 03:59:14 UTC
*** Bug 68403 has been marked as a duplicate of this bug. ***
Comment 11 Michael Stahl (allotropia) 2013-10-09 22:42:32 UTC
adjust version according to comment #7
Comment 12 retired 2013-11-24 09:26:12 UTC
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 :)
Comment 13 freeseek 2013-11-24 20:23:05 UTC
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.
Comment 14 etiffany 2013-11-24 21:08:44 UTC
Created attachment 89721 [details]
Test file with embedded EPS image (and SVG for comparison)
Comment 15 etiffany 2013-11-24 21:12:02 UTC
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).
Comment 16 etiffany 2013-11-24 21:13:17 UTC
Created attachment 89722 [details]
Output of Export As PDF produced by LO
Comment 17 etiffany 2013-11-24 21:13:57 UTC
Created attachment 89723 [details]
Output of Export As PDF using OpenOffice, for comparison
Comment 18 tommy27 2013-12-29 08:48:49 UTC
set status to NEW because of previous confirmations.
Comment 19 Rob Mercado 2013-12-29 09:00:58 UTC
I will be out of the office until Monday, January 6th, 2014.

If you have an emergency please send and email to rt-skokie.
Comment 20 V Stuart Foote 2014-04-27 15:54:13 UTC
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).
Comment 21 Commit Notification 2014-04-28 19:52:30 UTC
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.
Comment 22 Caolán McNamara 2014-04-29 10:45:54 UTC
Created attachment 98174 [details]
the extracted eps
Comment 23 Caolán McNamara 2014-04-29 11:00:35 UTC
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
Comment 24 Commit Notification 2014-04-29 11:01:36 UTC
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.
Comment 25 Jean-Baptiste Faure 2014-04-29 11:25:27 UTC
*** Bug 75216 has been marked as a duplicate of this bug. ***
Comment 26 Jean-Baptiste Faure 2014-04-29 11:27:31 UTC
*** Bug 77339 has been marked as a duplicate of this bug. ***
Comment 27 V Stuart Foote 2014-04-30 06:07:24 UTC
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.
Comment 28 V Stuart Foote 2014-04-30 06:13:11 UTC
Created attachment 98208 [details]
Export to PDF of test ODP impress with inserted EPS and EMF
Comment 29 V Stuart Foote 2014-04-30 06:14:22 UTC
Created attachment 98210 [details]
test ODP impress with inserted EPS and EMF
Comment 30 V Stuart Foote 2014-04-30 07:12:45 UTC
Created attachment 98213 [details]
rif on attachement 98174, parsed through Inkscape
Comment 31 V Stuart Foote 2014-04-30 07:22:29 UTC
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.
Comment 32 V Stuart Foote 2014-04-30 07:23:02 UTC
Created attachment 98217 [details]
PDF export from draw rendering of EPS and EMF as fixed
Comment 33 Enrique 2014-04-30 13:14:54 UTC
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."
Comment 34 Commit Notification 2014-05-14 13:21:03 UTC
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.
Comment 35 Enrique 2014-05-16 14:56:04 UTC
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))
Comment 36 Enrique 2014-05-16 14:58:12 UTC
Sorry, in previous comment I wanted to say "test doc from comment 14", not 34
Comment 37 Gerry 2014-07-21 09:30:46 UTC
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
Comment 38 Gerry 2014-07-21 09:31:50 UTC
Created attachment 103178 [details]
EPS-in-Writer-document-does-not-get-exported-in-L425.pdf
Comment 39 Gerry 2014-07-21 09:32:50 UTC
Created attachment 103179 [details]
EPS-in-Writer-document-does-not-get-exported-in-L425.odt
Comment 40 tommy27 2014-07-21 11:52:33 UTC
@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?
Comment 41 Gerry 2014-07-21 12:45:29 UTC
@tommy27: Done. I created bug 81598
Comment 42 tommy27 2014-07-21 12:55:16 UTC
thanks Gerry for your understanding.
reverting status to FIXED. let's continue discussion about residual issues on those new reports.