bug#34836 is an unreadable mess - but one of its problems is that of not being able to find pstoedit in it's path. 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.
Making this an easy-hack. The code is in: filter/source/graphicfilter/ieps/ieps.cxx If the initial spawning of that filter fails, we should probably hard-code a set of other paths particularly: /opt/local/bin - which seems to be where Mac people like to hide this out of their path these days ;-) Thanks !
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility. see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Removing comma from whiteboard (please use a space to delimit values in this field) https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Getting_Started
There was a similar issue with ieps.cxx for Windows builds to find correct path to ImageMagick convert.exe (see AOO issue 72096) Caolan M. fixed that back in Nov 2009, perhaps a similar approach for OSX and pstoedit?
*** Bug 85748 has been marked as a duplicate of this bug. ***
*** Bug 89073 has been marked as a duplicate of this bug. ***
Here's one user's workaround (posted yesterday): "PDF export with @LibreOffice with embedded EPS figures is broken on OS X. Install pstoedit from Homebrew and launch LO from cmd line to fix." https://twitter.com/tlngy/status/578696155762163712
Can't we try to locate pstoedit at configuration time, and maybe add a configuration option --with-pstoedit?
Piet, how would what happens to be present on the machine where LO is built be relevant for what can be expected to be present on the end-user machine?
Apparently /usr/local/bin and /opt/local/bin are paths we need to explicitly look into to find this beastie if it is there. Armed with that - and a few minutes work - almost anyone can fix this by hacking the method below and doing a bit of testing. Downgrading the EasyHack to even easier. It's not even necessary to have a Mac I think.
I think we are just asking for trouble if we start running random 3rd-party binaries from /usr/local/bin (which normally does not even exist on a Mac) (or even /opt/local/bin, which probably only a dozen Mac users in the world even have). Such random behaviour might be what Linux users expect, but is not proper on a Mac. Either we provide the EPS export functionality using code bundled with LibreOffice, or use system-provided APIs for the functionality (there might well be such, at least the normal print dialog on OS X has a "Save as PostScript" choice in addition to "Save as PDF"). Or then we shouldn't even pretend to have such functionality. Of course, if LibreOffice would use the normal print dialog on OS X it would have PDF and PostScript export there already...
(In reply to Tor Lillqvist from comment #9) > Piet, how would what happens to be present on the machine where LO is built > be relevant for what can be expected to be present on the end-user machine? Sorry, you are right.
(In reply to Tor Lillqvist from comment #11) > I think we are just asking for trouble if we start running random 3rd-party > binaries from /usr/local/bin (which normally does not even exist on a Mac) > (or even /opt/local/bin, which probably only a dozen Mac users in the world > even have). > > Such random behaviour might be what Linux users expect, but is not proper on > a Mac. > Hmmm, not sure that makes any sense at all. By that rational any of the suitably licensed and compiled helper projects in /external are questionable as "not proper" on OS X or Windows builds. > Either we provide the EPS export functionality using code bundled with > LibreOffice, or use system-provided APIs for the functionality (there might > well be such, at least the normal print dialog on OS X has a "Save as > PostScript" choice in addition to "Save as PDF"). Or then we shouldn't even > pretend to have such functionality. > Absent a native postscript/eps interpreter--bug 67464--likely also landing in /external, LibreOffice will remain dependent on installations of 3rd party image handlers ghostscript, pstoedit and Imagemagick's convert. Folks should understand that it is extremely rare that the Windows user base ever has ghostscript installed, let alone ImageMagick or pstoedit. And, how many Linux distros actually bundle ImageMagick or pstoedit? So, sorry but it will remain incumbent on the user to configure their system with the "helper" programs that LO depends on and provide proper path. LibreOffice may be able to address that as Michael M. suggests. Meanwhile some effort to improve coverage in the Help and Wiki for OS X?
Surely the kind of hacks using the command-line as described in that link is exactly what we *don't* want people to have to use?
(In reply to V Stuart Foote from comment #13) > (In reply to Tor Lillqvist from comment #11) > > I think we are just asking for trouble if we start running random 3rd-party > > binaries from /usr/local/bin (which normally does not even exist on a Mac) > > (or even /opt/local/bin, which probably only a dozen Mac users in the world > > even have). > > > > Such random behaviour might be what Linux users expect, but is not proper on > > a Mac. > > > > Hmmm, not sure that makes any sense at all. By that rational any of the > suitably licensed and compiled helper projects in /external are questionable > as "not proper" on OS X or Windows builds. > > > Either we provide the EPS export functionality using code bundled with > > LibreOffice, or use system-provided APIs for the functionality (there might > > well be such, at least the normal print dialog on OS X has a "Save as > > PostScript" choice in addition to "Save as PDF"). Or then we shouldn't even > > pretend to have such functionality. > > > > Absent a native postscript/eps interpreter--bug 67464--likely also landing > in /external, LibreOffice will remain dependent on installations of 3rd > party image handlers ghostscript, pstoedit and Imagemagick's convert. > > Folks should understand that it is extremely rare that the Windows user base > ever has ghostscript installed, let alone ImageMagick or pstoedit. And, how > many Linux distros actually bundle ImageMagick or pstoedit? > > So, sorry but it will remain incumbent on the user to configure their system > with the "helper" programs that LO depends on and provide proper path. > LibreOffice may be able to address that as Michael M. suggests. > > Meanwhile some effort to improve coverage in the Help and Wiki for OS X? It was my tweet mentioned earlier today. I agree with Tor that running random binaries out /usr/local/bin is not a good idea and it is unreasonable to expect most users to have pstoedit and other binaries installed on their machines. I think that we should either bundle pstoedit, etc with Libreoffice until the native EPS interpreter lands or let the user specify the location of the binaries as a stopgap measure. I don't think we should remove the functionality because even though it is broken, some users (like me) were able to get it working just enough to get desired results. There are some rendering inconsistencies with the SVG backend which precludes me from using it full time over EPS.
> Of course, if LibreOffice would use the normal print dialog on OS X > it would have PDF and PostScript export there already... I think you're confused =) this is not about the print / export format - but about the problem of turning embedded postcript/EPS objects into something that we can work with - so that we can then print them to any format. And yes - we should in the end have a beautiful solution via. eg. xpost - but bundling all of ghostscript (which ps2edit uses) - doesn't seem like a great approach to me in the meantime =)
Ah! Yes, indeed I was a bit confused there, I just read the "EPS rendering" in the subject and thought of rendering *to* EPS. Still, my opinions about relying on 3rd-party command-line tools that might be present, or not, stands...
So, since this is mostly an issue of defining PATH, as an alternative to hardcoding a selection of common paths as Michael M. suggests for an "even easier" hack. Why not a little more ambitious hack and define a specific LibreOffice managed variable for each of these external dependencies. One each for ghostscript, pstoedit and convert? Either make it a UserPaths configurable in the Preferences -> Paths panel on OS X, or Tools -> Options -> Paths for the other OS? Assume it would be written into user profile as the other PATHS Or, add them to InternalPaths and could then be adjustable with Expert Configuration. ieps.cxx could then be tweaked to use what is available, rather than current fall through of pstoedit and then convert--both of which are ghostscript dependent.
why isn't this whole EPS filter an extension, bundling the horrible pstoedit thing or whatever else it needs so it actually works when users install it? imho the current implementation is an unsupportable anti-feature.
This used to work; then, it stopped working. By definition, this is a regression, and IMO one that, all things being equal, should be fixed.
Agreeing with mst here: Making this a self-contained extension is likely the best way to go ahead. Of course, anyone providing a band-aid fix for the internal implementation is welcome too. Beyond that, please note that bugzilla is not a platform for sharing personal opinions on prioritizing bugs. There are agreed workflows on that[1] and ultimately it is the prerogative of those doing the fixes to pick bugs. [1] https://wiki.documentfoundation.org/File:Prioritizing_Bugs_Flowchart.jpg and https://wiki.documentfoundation.org/Most_Annoying_Bugs
*** Bug 92644 has been marked as a duplicate of this bug. ***
Created attachment 119006 [details] Patch so gs rendering is prefered over pstoedit I appreciate the efforts to build in EPS rendering but as that looks like it won't happen soon what I'd really like to see is a way to restore the behavior of LibreOffice to what it was in 4.1, where it used gs to produce reasonable quality EPS images. I've attached a very simple patch which does that, not just for display, but also for printing and for PDF export. I've also attached a png file showing how very bad the current pstoedit based results can be. I should say the cases I've tested are all EPS figures which do NOT contain built in previews. The fix has really just been reversing the order of the RenderAsEMF and RenderAsBMP calls in filter/source/graphicfilter/ieps/ieps.cxx so that BMP is tried first. However in the attached patch I wrapped that change in an if_else_then controlled by whether the environment variable LO_PREFER_GS_FOR_EPS is defined. Doing so means the change is not enabled by default, and you can test the effect of the change without recompiling. The behavior should really be controlled by some new option in the LibreOffice settings, but that was much more than I wanted to try. I know you've heard it before from others, but I'd like to emphasize just how bad a regression this change away from GS towards pstoedit has been. In any practical sense for those of us who have existing documents using EPS plots this has a major loss-of-data bug. In my case I've been using LibreOffice for my main research notebooks for the past several years. I use EPS for many figures because it IS still THE STANDARD in many scientific publications. After upgrading to LibreOffice 4.2 I discovered that many of the critical plots in those notebooks had been turned into unreadable garbage. And it's completely impractical to go back over years of work and try to recreate the plots in some other format. If I've been less vocal in this forum than others its only because I'd kept multiple backups in multiple formats, including PDF's. But if I hadn't noticed the plot corruption, I could have accidentally overwritten those. After this, I'm probably going to start keeping paper copies again as an ultimate backup. I've also been able to keep an old 4.1.x version working until recently. But others haven't been as lucky. I know this patch may not fix all the problems with EPS rendering (especially where previews DO exist) and the use of the environment variable to control behavior isn't ideal, but this DOES restore the good EPS rendering that LibreOffice had for me in version 4.1.6. I hope you can incorporate some version of this. It really is important for any of us who rely on EPS graphics.
Created attachment 119007 [details] PNG example of problems with pstoedit rendering Here is the png file demonstrating the difference in rendering with LO_PREFER_GS_FOR_EPS defined (so gs is used) and with it NOT set, so pstoedit is used. In this case the problem comes because pstoedit doesn't properly clip the drawing region while gs does, but lots of other rendering problems occur in other plots. I realized after posting the above patch that I'd mistakenly appended this to BUG 67465 rather than the related but probably more relevant bug 67464 I'd intended to attach it too. Sorry about that. The above tests and patches WERE done on a Linux machine, rather than a Mac. Let me know if there is anything further I can do to help with this.
(In reply to Robert R. Howell from comment #23) Well the obvious thing is to simply break the path to pstoedit, or uninstall it. And to insure that ghostscript (or Imagemagick convert) is on path to perform the RenderAsBMP preview. With its very low quality rendering to EMF/WMF, pstoedit is really of questionable utility. It is not clear if the pstoedit paid EMF plugin improves things. Simply don't use it--then no need for an environment variable switch. The bigger issue for scientific and technical publication (once poor quality EMF/WMF preview rendering is removed) is that the substitute preview BMP is rendered at 300dpi. And those raster previews, while fine for on screen use, are passed out for printing or embedding into ps or PDF ( bug 81497 ) with loss of vector graphic quality needed for publication. Likewise, for EPS images with embedded TIFF previews--those low resolution previews are used as the RenderAsBMP is never called to regenerate them. And the original preview is passed for ps or PDF generation. Replacement of the preview might be worthwhile to implement for on screen use.
Removing pstoedit does work as a debugging test (that's partly how I isolated the problem) but it doesn't work in practice for most users because it breaks other software packages which rely on pstoedit. If there's a way to just remove it from the LibreOffice path could you let me know? But that still is a much more obscure fix for most users than simply providing an option to explicitly set the renderer preference. If it were just me I'd simply reverse the preference from the current one, but that might have negative impacts on others. I understand this patch doesn't fix all the problems, but the pdf and printer output I get from this is still a LOT better than with pstoedit. It may not provide the enhancements requested by some, but it DOES (at least for me) fix the very bad regression which started sometime after 4.1.6. And that regression for users who DID have tolerably working EPS rendering, is what has caused the most serious complaints.
(In reply to Robert R. Howell from comment #26) >... doesn't work in practice for most users because > it breaks other software packages which rely on pstoedit. Well on OS X or Windows that is not an issue--pstoedit is not routinely installed (nor is Imagemagick, nor ghostscript). And, few Linux distros bundle pstoedit by default. So, which other software (on Linux) do you perceive as pstoedit dependent? But guess if one has to have it for something substantive, might not be viable to hide it from path. > ... If there's a way > to just remove it from the LibreOffice path could you let me know? But that > still is a much more obscure fix for most users than simply providing an > option to explicitly set the renderer preference. No, your suggested environment approach would be the only way to toggle between WMF/EMF vector previews via pstoedit and "native" BMP rasters via Ghostscript or Imagemagick convert. Personally, the pstoedit EMF vector previews in LibreOffice are of such low quality, I'd prefer elimination of the RenderAsEMF methods [1] until a better option for vector previews can be implemented. =-ref-= [1] http://opengrok.libreoffice.org/xref/core/filter/source/graphicfilter/ieps/ieps.cxx#196
(In reply to V Stuart Foote from comment #27) > Well on OS X or Windows that is not an issue--pstoedit is not routinely > installed (nor is Imagemagick, nor ghostscript). And, few Linux distros > bundle pstoedit by default. So, which other software (on Linux) do you > perceive as pstoedit dependent? But guess if one has to have it for > something substantive, might not be viable to hide it from path. > Inkscape is the main package I use which requires pstoedit.
Migrating Whiteboard tags to Keywords: (easyHack, difficultyBeginner, skillCpp, topicCleanup)
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC) [NinjaEdit]
*** Bug 103674 has been marked as a duplicate of this bug. ***
I'm not a programmer so I'm wondering why EPS rendering is still working in Openoffice and why it's so difficult to get it working in Libreoffice. Isn't it possible to do it just the way it's done in Openoffice.
I had a workaround by adding the pstoedit path using 'launchctl config user path'. This was not pretty, and has stopped working with the upgrade to Big Sur. Running from a terminal works because 'pstoedt' is on my path, but it brings in a lot of other directories. They seem harmless, but I am not keen. The best solution I can some up with is to add the following line to my .zshrc file... alias soffice="set LO_PREFER_GS_FOR_EPS && set PATH && /Applications/LibreOffice.app/Contents/MacOS/soffice" If you type 'soffice' at a new terminal session, you get office using Ghostscript instead of pstoedit, so the EPS files appear in the PDF exports. Any better suggestions welcomed. Is there a neat way to set LO_PREFER_GS_FOR_EPS in the application itself?