Bug Hunting Session
Bug 67465 - EPS rendering: locating pstoedit on Mac a problem
Summary: EPS rendering: locating pstoedit on Mac a problem
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.1.0.3 rc
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL: http://ask.libreoffice.org/en/questio...
Whiteboard:
Keywords: difficultyBeginner, easyHack, skillCpp, topicCleanup
: 85748 89073 92644 103674 (view as bug list)
Depends on:
Blocks: MacOS-Wishlist Images-EPS
  Show dependency treegraph
 
Reported: 2013-07-29 09:53 UTC by Michael Meeks
Modified: 2019-02-21 19:21 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Patch so gs rendering is prefered over pstoedit (1.58 KB, patch)
2015-09-25 04:44 UTC, Robert R. Howell
Details
PNG example of problems with pstoedit rendering (54.15 KB, image/png)
2015-09-25 04:55 UTC, Robert R. Howell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2013-07-29 09:53:09 UTC
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.
Comment 1 Michael Meeks 2013-07-29 09:59:07 UTC
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 !
Comment 2 Björn Michaelsen 2013-10-04 18:47:02 UTC
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
Comment 3 Robinson Tryon (qubit) 2013-10-23 17:24:44 UTC Comment hidden (obsolete)
Comment 4 V Stuart Foote 2014-04-27 19:36:09 UTC
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?
Comment 5 V Stuart Foote 2015-03-11 04:37:25 UTC
*** Bug 85748 has been marked as a duplicate of this bug. ***
Comment 6 V Stuart Foote 2015-03-11 04:38:20 UTC
*** Bug 89073 has been marked as a duplicate of this bug. ***
Comment 7 Robinson Tryon (qubit) 2015-03-20 13:22:53 UTC
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
Comment 8 Pieter van Oostrum 2015-03-20 13:28:45 UTC
Can't we try to locate pstoedit at configuration time, and maybe add a configuration option --with-pstoedit?
Comment 9 Tor Lillqvist 2015-03-20 13:55:24 UTC
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?
Comment 10 Michael Meeks 2015-03-20 13:58:13 UTC
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.
Comment 11 Tor Lillqvist 2015-03-20 14:08:44 UTC
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...
Comment 12 Pieter van Oostrum 2015-03-20 14:25:19 UTC
(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.
Comment 13 V Stuart Foote 2015-03-20 15:31:58 UTC
(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?
Comment 14 Tor Lillqvist 2015-03-20 16:01:09 UTC
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?
Comment 15 Tamas Nagy 2015-03-20 16:03:47 UTC
(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.
Comment 16 Michael Meeks 2015-03-20 17:28:01 UTC
> 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 =)
Comment 17 Tor Lillqvist 2015-03-20 17:46:43 UTC
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...
Comment 18 V Stuart Foote 2015-03-20 18:01:00 UTC
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.
Comment 19 Michael Stahl (CIB) 2015-03-23 15:16:50 UTC
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.
Comment 20 felipe 2015-03-23 15:30:17 UTC
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.
Comment 21 Björn Michaelsen 2015-03-23 16:58:35 UTC
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
Comment 22 V Stuart Foote 2015-09-10 13:59:45 UTC
*** Bug 92644 has been marked as a duplicate of this bug. ***
Comment 23 Robert R. Howell 2015-09-25 04:44:47 UTC
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.
Comment 24 Robert R. Howell 2015-09-25 04:55:34 UTC
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.
Comment 25 V Stuart Foote 2015-09-25 14:32:31 UTC
(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.
Comment 26 Robert R. Howell 2015-09-25 17:23:33 UTC
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.
Comment 27 V Stuart Foote 2015-09-25 18:14:33 UTC
(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
Comment 28 Robert R. Howell 2015-09-25 21:37:09 UTC
(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.
Comment 29 Robinson Tryon (qubit) 2015-12-10 11:41:04 UTC Comment hidden (obsolete)
Comment 30 Robinson Tryon (qubit) 2016-02-18 14:51:38 UTC Comment hidden (obsolete)
Comment 31 Alex Thurgood 2016-11-03 11:58:46 UTC
*** Bug 103674 has been marked as a duplicate of this bug. ***
Comment 32 flitzdimpfel 2016-11-03 12:10:21 UTC
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.