Created attachment 43931 [details] An ODT-file with an EPS-image and the exported PDF file. I have a document with an EPS image included. The image is display fine in LibreOffice. However, the image is omitted in exported PDF files and a box with red comments on the file is drawn. A sample document is attached. TIA for fixing this issue, Wolfgang
I can not reproduce on Mac OSX 10.6.6 with LibreOffice 3.3.2 RC1. I have attached a PDF file created via the PDF icon from a Writer document into which I inserted a PS3 EPS file created originally in Inkscape. As you should be able to see from the PDF, the EPS file is displayed correctly. Alex
Created attachment 44473 [details] test PDF export of ODT incorporating PS3 EPS image This PDF file was made by exporting to PDF from an ODT containing an inserted EPS file.
setting needinfo keyword
Hi Wolfgang, I also tested with the files your provided. If I click on the PDF export in LibreOffice 3.3.2 RC1 under Mac OSX 10.6.6, I get a PDF file in which I see your graph EPS just fine. So I can not reproduce your problem. Alex
Hi Alex, Thanks for looking at this issue, my example definitely fails with 3.3.1, I will turn to 3.3.2rc1 to see, whether this fixes my issue. Wolfgang
Alex, LIbO-3.3.2rc1 shows the same behaviour on my box, no image in PDF output :( Is there any additional dependency like ghostscript required in order to get this working? Regards, Wolfgang
Hi Wolfgang, No idea I'm afraid, but I do have ghostscript version 9.01 installed on my system. This contains a certain number of utilities, including eps Alex
Alex, I've now installed ghostscript-8.71 to /usr/local/bin, which was the only binary I could find at the moment. However, the export behavior did not change. No EPS image in PDF export :( I'm really clueless at this point, do you have a possibility to check my files on a machine, which is not crowded with developer tools. Or is this a localization issue ? Regards, Wolfgang
Hi Wolfgang, On the French users list, someone has been able to reproduce your problem on Mac OSX 10.6. We are trying to find out what the differences might be. Perhaps there is an image library that I have installed through the ports system that enables the image to be displayed ? My ghostscript installation was built via the ports system. I will try on a Tiger machine and report back. Alex
Alex, ThX very much digging into this issue, Wolfgang
Alex, I switched to LibO-3.3.2rc2, no change, no EPS in PDF output :( Wolfgang
Bug is still present in LibO-3.3.2 release. Is there anything I can help in sorting this out? Regards, Wolfgang
Created attachment 45154 [details] Output of dtrace -p <pid> during a PDF export Alex, I took the time and analyzed the LibreOffice process during my export using dtrace. The IMHO relevant portion is cited below and essentially searches for the programs 'pstoedit' and 'convert' in '.', '/usr/bin', '/bin', '/usr/sbin' and '/sbin', in order. None of these programs is found, I don't have a clue, why LibreOffice needs these and where they should come from. Best regards, Wolfgang *********************************************** read_nocancel(0x23, "%!PS-Adobe-2.0 EPSF-2.0\n%%Title: clipper.fig\n%%Creator: fig2dev Version 3.2 Patchlevel 5c\n%% CreationDate: Sun Feb 13 13:58:42 2011\n%%BoundingBox: 0 0 409 289\n%Magnificati on: 1.0000\n%%EndComments\n%%BeginProlog\n/$F2psDict 200 dict def\n$F2psDict begin\n$F2psDi", 0x224B) = 8779 0 getattrlist("/tmp\0", 0xBFFF7D68, 0xBFFF79F0) = 0 0 geteuid(0xBFFF9DA0, 0xBFFF7D68, 0xBFFF79F0) = 501 0 geteuid(0xBFFF9DA0, 0xBFFF7D68, 0xBFFF79F0) = 501 0 geteuid(0xBFFF9DA0, 0xBFFF7D68, 0xBFFF79F0) = 501 0 geteuid(0xBFFF9DA0, 0xBFFF7D68, 0xBFFF79F0) = 501 0 getattrlist("/.vol/234881026/24965\0", 0xBFFF73C4, 0xBFFF6FB0) = 0 0 getattrlist("/tmp/sv5jl.tmp\0", 0xBFFF7D68, 0xBFFF79F0) = -1 Err#2 statfs(0xBFFF9DA0, 0xBFFFA1A0, 0xBFFF79F0) = -1 Err#2 open_nocancel("/tmp/sv5jl.tmp\0", 0x20A26, 0x1B6) = 38 0 fcntl_nocancel(0x26, 0x3, 0x0) = 16390 0 fcntl_nocancel(0x26, 0x4, 0x4002) = 0 0 fstat(0x26, 0xBFFFA2B0, 0x4002) = 0 0 close_nocancel(0x26) = 0 0 getuid(0x26, 0xBFFFA2B0, 0x4002) = 501 0 access("./pstoedit\0", 0x0, 0x4002) = -1 Err#2 access("/usr/bin/pstoedit\0", 0x0, 0x4002) = -1 Err#2 access("/bin/pstoedit\0", 0x0, 0x4002) = -1 Err#2 access("/usr/sbin/pstoedit\0", 0x0, 0x4002) = -1 Err#2 access("/sbin/pstoedit\0", 0x0, 0x4002) = -1 Err#2 bsdthread_create(0xBA60, 0x22D7F8C0, 0x80000) = -1334398976 0 fork() = 1001 0 close_nocancel(0x2A) = 0 0 close_nocancel(0x2B) = 0 0 close_nocancel(0x2E) = 0 0 close_nocancel(0x30) = 0 0 read_nocancel(0x26, "\002\0", 0x4) = 4 0 close_nocancel(0x26) = 0 0 close_nocancel(0x2C) = 0 0 close_nocancel(0x2D) = 0 0 close_nocancel(0x2F) = 0 0 getattrlist("/tmp\0", 0xBFFF7FC8, 0xBFFF7C50) = 0 0 geteuid(0xBFFF9FB0, 0xBFFF7FC8, 0xBFFF7C50) = 501 0 geteuid(0xBFFF9FB0, 0xBFFF7FC8, 0xBFFF7C50) = 501 0 geteuid(0xBFFF9FB0, 0xBFFF7FC8, 0xBFFF7C50) = 501 0 geteuid(0xBFFF9FB0, 0xBFFF7FC8, 0xBFFF7C50) = 501 0 getattrlist("/.vol/234881026/24965\0", 0xBFFF7624, 0xBFFF7210) = 0 0 getattrlist("/tmp/sv5jl.tmp\0", 0xBFFF7FC8, 0xBFFF7C50) = 0 0 geteuid(0xBFFF9FB0, 0xBFFF7FC8, 0xBFFF7C50) = 501 0 geteuid(0xBFFF9FB0, 0xBFFF7FC8, 0xBFFF7C50) = 501 0 geteuid(0xBFFF9FB0, 0xBFFF7FC8, 0xBFFF7C50) = 501 0 geteuid(0xBFFF9FB0, 0xBFFF7FC8, 0xBFFF7C50) = 501 0 getattrlist("/.vol/234881026/4857343\0", 0xBFFF7624, 0xBFFF7210) = 0 0 lstat("/tmp/sv5jl.tmp\0", 0xBFFF9F30, 0xBFFF7210) = 0 0 unlink("/tmp/sv5jl.tmp\0", 0xBFFF9F30, 0xBFFF7210) = 0 0 getuid(0xBFFF9FB0, 0xBFFF9F30, 0xBFFF7210) = 501 0 access("./convert\0", 0x0, 0xBFFF7210) = -1 Err#2 access("/usr/bin/convert\0", 0x0, 0xBFFF7210) = -1 Err#2 access("/bin/convert\0", 0x0, 0xBFFF7210) = -1 Err#2 access("/usr/sbin/convert\0", 0x0, 0xBFFF7210) = -1 Err#2 access("/sbin/convert\0", 0x0, 0xBFFF7210) = -1 Err#2 bsdthread_create(0xBA60, 0x22D7F8C0, 0x80000) = -1334398976 0 thread_selfid(0x0, 0x0, 0x0) = 39051 0 socketpair(0x1, 0x1, 0x0) = 0 0 ***********************************************
Hi Wolfgang, The only thing I can think of is that the PDFexport on your machine is using a ps conversion routine, hence the search for pstoedit. I don't have pstoedit on my machine, although it is in the macports repository. What I do have however, are the following ps conversion utilities : ps2ascii ps2epsi ps2pdf ps2pdf12 ps2pdf13 ps2pdf14 ps2pdfwr ps2ps ps2ps2 So I clearly have one that can deal with encapsulated postscript conversion. As it turns out, this was installed via ports with ghostscript 9.01: /opt/local/bin/ps2epsi Alex
Alex, ThX for your response. In the meanwhile I have installed gs-9.01 from MacPorts, too. However, the EPS image is only generated inside the PDF file, if I start /Applications/LibreOffice.app/Contents/program/soffice from the command line, where /opt/local/bin is on my path. If I start LibreOffice from the normal application icon, the EPS file is not exported, because /opt/local/bin not seems to be part of $PATH when starting this way. So, we know, that LibreOffice definitely needs ghostscript to process EPS files during PDF export. Furthermore, the exported PDF file has a pixel version of my EPS file rather than a vector version as supposed by your example. (I will attach this file in a minute...) Best regards, Wolfgang
Created attachment 45178 [details] PDF export of my example with MacPorts' gs-9.01 on $PATH This PDF export has my EPS file included, but in pixelized form. A vector version would be very much appreciated.
Created attachment 45191 [details] The export results after installing ImageMagick using MacPorts Alex, after installing ImageMagick using Macports and starting LibO from the command line, I got the attached result. The EPS file is still converted to a pixel format, this time with much better antialiasing :) So, we have two issues here: 1) LibO silently uses ghostscript or preferably ImageMagick when exporting EPS files to PDF, which IMHO seems to be underdocumented. Moreover, we should work out a suggestion for the LibO installer in order to warn users, if no ImageMagick or ghostscript is available. Maybe the installer should perform an additional check for binaries in /opt/local/bin, which is not on the user's path per default. 2) The EPS to PDF export uses a pixel format, a conversion of eps to a PDF-XObject with PDF drawing commands seems to be unimplemented. I think we should file this one as a separate bug, if this has not been done before. What do you think about all this? Best regards, Wolfgang
Seems to be partially resolved in 3.4Beta3. PDF export is ok now from writer with embedded EPS, BUT: PRINTING a page with embedded EPS from writer to a PS-Printer fails, resulting in a sheet covered with whitespace. If printing to a PS-file and later opening the file with ghostview / ghostscript, for a short time the correct content of the page could be seen, before it is overlayed with whitespace. Probably the bounding box of the EPS graph is neglected by the print module. This issue is persistent since the beginning of OpenOffice. If there is only one EPS-Image per page, it should be helpful (for PS printers), to print the EPS before the remaining content of the page. System Environment: WinXP Home SP3 german version Adobe Type Manager ATM Lite ver. 4.1 Build 243 LibreOffice 3.4Beta3 German Version /w German Helppack GSVIEW32 Rev. 4.9 Ghostscript 9.00 Okipage C5750 Postscript Mode @USB TI MicroLaser PowerPro PS23 @ LPT1: Adobe Generic Color Postscript Printer For Commercial Printing @ File
Looks like the old bug from OpenOffice http://openoffice.org/bugzilla/show_bug.cgi?id=14163 made it into libreOffice. No change in 3.4.2 on openSUSE 11.3
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
needinfo keyword redundant by needinfo status.
In 3.5.0 version problem still exist?
(In reply to comment #22) > In 3.5.0 version problem still exist? Easily reproducible with * LibreOffice 3.5.4.2 (Build-ID: 165a79a-7059095-e13bb37-fef39a4-9503d1) * LibreOffice 3.6.0.0.beta3 (Build ID: 3e2b862) both on on MacOS X 10.6.8 German. Well, I think we need someone who will finally try to fix this ...
Still REPRODUCIBLE with * LibreOffice 3.5.6.2 (Build-ID: e0fbe70-dcba98b-297ab39-994e618-0f858f0) * LibreOffice 3.6.1.1 (Build ID: 4db6344) both with German langpack installed, on MacOS X 10.6.8 (Intel).
*** Bug 41174 has been marked as a duplicate of this bug. ***
@Thorsten Behrens: This is yet another MacOS-only issue. Please take a look at it. Importance of the bug: The FLOSS community might prefer SVG over EPS graphics now, but PDF export is still of importance especially for users coming from a DTP background, but also "ordinary" users will sometimes still uses company signs, artwork etc. in EPS format. Additionally, it should be not that difficult to fix this, given the fact that EPS in PDF export seems to work fine on Linux! Thank you very much in advance! If you know about any other developer who is experienced in EPS/PDF issues and should/could be contacted, please inform him about this bug or let me know about the developer so that I can contact him. Thank you!
*** Bug 46313 has been marked as a duplicate of this bug. ***
Alex, if you look closely at the PDF you posted (i.e. zoom in reeaally far in Acrobat Reader -- Okular e.g. will not zoom far enough!) you will see that the EPS image in the document has been rasterized during the export. It is no longer a vector image! The only way I have found to preserve vector images when generating a PDF is either to use EMF or WMF (which have other problems...) or to print to a (virtual) postscript printer, redirect to a file and then use: ps2pdf -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode print.ps print.pdf The two parameters are just for keeping raster graphics from being resampled and turned into JPEGs, so you can omit them. I'm not quite sure what LO does under the hood during PDF export, but I did not find any option that will leave eps images intact, and rasterizing them can lead to ridiculous file sizes if you have a larger amount of EPS line graphs (which I do), and spoil the printing results badly if you have fine detail (which I do, too). For rasterized images I'd also like to have an option not to touch them, (right now you can either convert all to JPEG or all to PNG), but that is a different issue. Since I think that internally LO is also using PS2PDF or some other ghostscript commands to generate the PDF, I think it should be possible offer both options (preserve vector properties of EPS and leave raster graphics untouched) using the builtin PDF export. Thanks for reading, Zak
(In reply to comment #26) > Importance of the bug: > The FLOSS community might prefer SVG over EPS graphics now, but PDF export is > still of importance especially for users coming from a DTP background, but also > "ordinary" users will sometimes still uses company signs, artwork etc. in EPS > format. In my particular case, the EPSes are MATLAB plots, and EPS is the only vector export format which that software supports. While I agree that SVG is the way to go for FLOSS (especially given that any modern browser can be used as an impromptu SVG viewer), plenty of users will need EPS for some time to come because other applications they use won't support SVG (ever). This bug is repeatable for me with 3.6.1.1 on OS X Lion. The problem (a white square with red text appearing in the PDF output in place of the actual EPS graphic) DOES occur with OpenOffice 3.4.1 on OS X, but NOT with NeoOffice 3.2.1. If there's any DTrace incantations that I can invoke to provide the developers with more information as to why this is working in NeoOffice but not OO or LO, please let me know. One other note about my rig: I *do* have ps2epsi in /usr/bin (symlinked from /opt/local/bin, where it was installed by MacPorts), but do not have ImageMagick or pstoedit installed anywhere. Given that NeoOffice apparently doesn't need any of those utilities to perform the same export function (nor does it include any of them in the Mac app bundle), I'm less inclined to believe that the lack thereof is really the problem.
Just a follow-up: for LibreOffice v 3.6.2.1 (Build ID: ba822cc) on Mac OS X 10.7.something, I've found a successful workaround (provided you have MacPorts installed, or can be bothered to install it [http://www.macports.org/install.php]). THE WORKAROUND: Install 'pstoedit' from MacPorts. Note that this pulls ImageMagick in as as dependency, so I don't know for sure whether 'pstoedit' or ImageMagick solves the problem. I just want to document this clearly here for any Mac users, to ease the pain of not having EPS support in LO "as shipped."
(In reply to comment #30) > Just a follow-up: for LibreOffice v 3.6.2.1 (Build ID: ba822cc) on Mac OS X > 10.7.something, I've found a successful workaround (provided you have > MacPorts installed, or can be bothered to install it > [http://www.macports.org/install.php]). > > > THE WORKAROUND: Install 'pstoedit' from MacPorts. > > > Note that this pulls ImageMagick in as as dependency, so I don't know for > sure whether 'pstoedit' or ImageMagick solves the problem. I just want to > document this clearly here for any Mac users, to ease the pain of not having > EPS support in LO "as shipped." I tried this and it did not work for me. I still have the same problem with my eps images (from MATLAB) not exporting from Draw. I did find that going through the OS X print dialog and saving as PDF kept the images properly. However, I'll need to create a new printer that lets me print the correct size (4'x6') before sending to IT for poster printing. This is a really annoying bug! OS X.7.5, LO Version 3.6.3.2
(In reply to comment #31) > I tried this and it did not work for me. I still have the same problem with > my eps images (from MATLAB) not exporting from Draw. I did find that going Wow. I'm very sorry. I set up a dummy account to check and see if it was an issue of pstoedit or ps2epsi or something else not being in the path and discovered that it no longer works with my *own* account--if it ever did. I was pretty certain when I posted my last comment; now I'm not. (Granted, this is several minor point releases later, so maybe there was a regression.) I can attest to the fact that NeoOffice *does* successfully export an ODF document with an embedded EPS to PDF, albeit rendered to a bitmap at what appears to be about 300 dpi. If that's any consolation. Be forewarned that I have the "paid" version of NeoOffice (v.3.3 patch 2, currently), so your mileage may vary with the free download. I realize this doesn't add any substance to the bug report (and my apologies to the devs on the cc list for this bug), but consider this a retraction to my previous "WORKAROUND" comment. For now.
I regularly create business documents in LO, using a standard JPEG to produce a letterhead background on the first page. Then I export the document to PDF to send as an e-mail attachment. This worked perfectly with many recent versions of LO, specifically 3.5.4 most recently. But suddenly in 3.6.3 the background JPEG is totally missing from the PDF (the formatting of the text section is well-maintained).
Basil: please file a separate bug and attach ODS and PDF examples of the problem. The bug the current report deals with is completely different: it does not cover JPEG images and has been present for more versions than you reported.
> The bug the current report deals with is completely different: [... Correct (thank you, Milan!). So let’s reset the changed meta data, too.
*** Bug 64718 has been marked as a duplicate of this bug. ***
*** Bug 62499 has been marked as a duplicate of this bug. ***
*** Bug 64161 has been marked as a duplicate of this bug. ***
Joren provided a bibisect in fdo#64161, see https://bugs.freedesktop.org/show_bug.cgi?id=64161#c5 Put all, since it affects at least 2 envs (MacOs + Linux)
I think the bug in libreoffice 4 is newly introduced. On the same computer I have both 3.6 and 4. 3.6 can export PDF file correctly, while 4.0 can not. Furthermore, when I try to convert the eps image into bitmap, the image also disappeared.
Bisected with help for bibisect from fdo#64161. First bad commit: 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: $ git bisect log # bad: [ae4e4a11d4300f7448cb6bd170fcb034542caddc] typo... # good: [777d6de361cca2ee0ba2b6d41952107e8d8c0307] -Werror,-Wc++98-compat-pedantic git bisect start 'ae4e4a11' '777d6de361cca2ee0ba2b6d41952107e8d8c0307' # skip: [1a6a3a12a9247ad18bc68d77b48229e457c7a9c0] In the 10.7 SDK CoreText is in the ApplicationServices framework git bisect skip 1a6a3a12a9247ad18bc68d77b48229e457c7a9c0 # good: [a94b902736ad2cc74224cad4ae64f83880ece632] sal_Bool to bool git bisect good a94b902736ad2cc74224cad4ae64f83880ece632 # skip: [b76d45e3153f47125f841c8d6c5827291d1536b8] Revert "detect even more memory mismanagement on glibc" git bisect skip b76d45e3153f47125f841c8d6c5827291d1536b8 # skip: [04f4a0c1366d1863b93d7d84a8534791696b7477] Somehow this change was lost during git rebase. git bisect skip 04f4a0c1366d1863b93d7d84a8534791696b7477 # good: [95cf9d5a48232e45cded632ef440420db1c26866] warn when trying to export a conditional format that is not supported git bisect good 95cf9d5a48232e45cded632ef440420db1c26866 # good: [13fa07a4e369ad24ce7279292fb6604f57f86691] implement text cond formats ooxml import git bisect good 13fa07a4e369ad24ce7279292fb6604f57f86691 # good: [a6ac5b2a9e4298f7e187dd42eaa8a8587b1693c9] fix build with glibc 2.16 git bisect good a6ac5b2a9e4298f7e187dd42eaa8a8587b1693c9 # bad: [b9c98414ec9084cf97b5dcc911fb9941b5e57ebb] Added Tango colors to palette git bisect bad b9c98414ec9084cf97b5dcc911fb9941b5e57ebb # good: [73f89b5d36dbae26072a1e749f10dfd6ffb6dd6e] impress211: #i116911# Accept -1 as special value for multi monitor support. git bisect good 73f89b5d36dbae26072a1e749f10dfd6ffb6dd6e # skip: [6f79b2e35be0778bfec3e1854483f2e9a68f68f3] Revert "if/else placement" git bisect skip 6f79b2e35be0778bfec3e1854483f2e9a68f68f3 # bad: [85ea03ae536831649b104694d08dced4d4c8663f] fdo#55430 allow clicking objects in front of selected ones git bisect bad 85ea03ae536831649b104694d08dced4d4c8663f # bad: [44cfc7cb6533d827fd2d6e586d92c61d7d7f7a70] re-base on ALv2 code. Includes (at least) relevant parts of: git bisect bad 44cfc7cb6533d827fd2d6e586d92c61d7d7f7a70 # skip: [1865174e30d23f3eb85b7600cb33f29b8d4557d4] impress211: fix a rebase problem git bisect skip 1865174e30d23f3eb85b7600cb33f29b8d4557d4 # skip: [2a755f3af94d8bb0184d1045ac46f0f1f5bcf46d] impress211: #i110990# Fixed slide show spanning multiple displays on Windows. git bisect skip 2a755f3af94d8bb0184d1045ac46f0f1f5bcf46d # good: [eff92f2501cf070cd912508b2ccc3c0108d0327c] aw084: #i108052# Added code to mimic old behaviour git bisect good eff92f2501cf070cd912508b2ccc3c0108d0327c
Björgvin: thank you for the bibisect work! I supposed you did it like Joren did, so put "bibisected40" in Whiteboard. Michael: I noticed in the commit this: file filter/source/graphicfilter/eps/eps.cxx case( META_RENDERGRAPHIC_ACTION ): part has been removed. Could it be related?
Julien: This is a bisect which identifies the exact source code commit which introduced the bug. (unlike the bibisect from Joren which identified a range of possible commits) Unfortunately this commit is a huge code import from AOO. I tested AOO 3.4.1 and the bug is present these, so this is not the result of a faulty code import. I have been playing around with the code and I think it's likely that this is a result of the removal of META_RENDERGRAPHIC_ACTION as you mentioned. Here is the AOO commit: http://svn.apache.org/viewvc?view=revision&revision=1220836 . I've tried to revert the removal of META_RENDERGRAPHIC_ACTION but it's progressing slowly. Also, this bugfix should be accompanied with a unit-test.
> Unfortunately this commit is a huge code import from AOO. Right - and as such we cannot revert any part of it without causing severe problems. Of course, we can research the differences that cause this issue and then re-fix the bug; that is not a problem. If you have questions on that please contact me by private mail not in this bug. This bug looks like it is becoming unmanageable - it seems to include lists of un-related issues, it's getting hard to read - which hugely decreases the likelihood that any developer will get to the end and be able to fix this bug. It is the kind of bug that can never be 'fixed' because one of the several sub-branches of the bug will get it re-opened, and everyone ends up un-satisfied. EPS is a subset of postscript that LibreOffice cannot render by itself. We require an external program to convert this to a bitmap - it would be a nice enhancement to fix that so we had an embedded EPS interpreter - however, that is a rather significant enhancement request - it needs splitting into a new bug. Possibly we have (somehow) mangled and reduced the resolution of the pixel image we render as a consequence of including Armins' changes in the re-base. If so, we need to look at the DPI handling around that I imagine - it would be good to pick one of the duplicates that is clean, and swap the order here - make this one a duplicate of that bug - and make that bug a MAB for 4.0 - so we solve it. Rendering EPS requires pstoedit thus: static bool RenderAsEMF(const sal_uInt8* pBuf, sal_uInt32 nBytesRead, Graphic &rGraphic) { TempFile aTemp; aTemp.EnableKillingFile(); OUString fileName("pstoedit" EXESUFFIX); OUString arg1("-f"); OUString arg2("emf:-OO"); OUString arg3("-"); OUString output; osl::FileBase::getSystemPathFromFileURL(aTemp.GetName(), output); rtl_uString *args[] = { arg1.pData, arg2.pData, arg3.pData, output.pData }; If the program is not in your path - it will not be found. We could of course try to add a series of paths to try in this eventuality but that should be a separate issue. Again. Can I have help from a QA guy to close this issue, spawn several others and get the problems split up nicely !? :-) Thanks.
Michael: must have missed something but why several bugtrackers? We could either transform this one into enhancement with this title for example: "Rendering EPS broken on MacOs". or, because as you said and I agree with you, this one became unmanageable, close this one as Won't fix and create a enhancement bugtracker (with title previously quoted). BTW: I naively gave a try with the first file attached on pc Debian x86-64 4.0.3 Debian LO packages, everything is ok. However, with LO 4.0.3 and a brand new LO profile on MacOs 10.7, I reproduce the exact pdf included on the first attached zip.
Its still not working with 4.0.4.2. at Mac Lion.
Sisyphus: where is pstoedit installed on your system ?
A possible workaround for the pstoedit utility not being found (on the $PATH) under MacOS 10.7+ is offered in this AskLO answer: http://ask.libreoffice.org/en/question/20188/how-to-export-pdf-with-eps-image-in-writer/?answer=20475#post-id-20475 The relevant bit is: For example if your "pstoedit" is in "/opt/local/bin" your LO maynot be able to find it, therefore the export PDF with EPS image will be fail. Since Lion, the GUI app environment PATH is only affected by "launchctl" command. In my case, here is what I did: p=$(launchctl getenv PATH) launchctl setenv PATH /opt/local/bin:/opt/local/sbin:$p Note: I have not tested this myself. I am merely reporting this here for others.
This bug is too huge, tangled and un-readable for any developer to get to the end of. To save time and avoid repeated waste I've split it into: bug#67464 - request for built-in EPS rendering (a long term enhancement) bug#67465 - try harder to find pstoedit on Macs One of these is tractable. Julien asked: > Michael: must have missed something but why several bugtrackers? Because one very long, overly complicated multi-comment bug with multiple issues in it is a disaster: it wastes programmers time to read, and then they realise that there will never be a clean fix even of the easy bit because somehow someone put a man-year task next to a 10 man minute task in the same bug - so ... > We could either transform this one into enhancement with this title for > example: "Rendering EPS broken on MacOs". Long, unclear, confused, unreadable bugs waste very significant time trying to unwind them. I've split it into two clear, precise bugs that can be read quickly and (I hope) gives a developer a reasonable incentive to fix one of them: the trivial bit - and the satisfaction of at least closing a bounded problem :-) HTH.
I reopened #64161 to track the regression between 3.6 and 4.0.