<html>
    <head>
      <base href="https://bugs.documentfoundation.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - EPS rendering: locating pstoedit on Mac a problem"
   href="https://bugs.documentfoundation.org/show_bug.cgi?id=67465#c15">Comment # 15</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - EPS rendering: locating pstoedit on Mac a problem"
   href="https://bugs.documentfoundation.org/show_bug.cgi?id=67465">bug 67465</a>
              from <span class="vcard"><a class="email" href="mailto:tlngy+libreoffice@fastmail.com" title="Tamas Nagy <tlngy+libreoffice@fastmail.com>"> <span class="fn">Tamas Nagy</span></a>
</span></b>
        <pre>(In reply to V Stuart Foote from <a href="show_bug.cgi?id=67465#c13">comment #13</a>)
<span class="quote">> (In reply to Tor Lillqvist from <a href="show_bug.cgi?id=67465#c11">comment #11</a>)
> > 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--<a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Request for built-in EPS rendering ..."
   href="show_bug.cgi?id=67464">bug 67464</a>--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?</span >

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.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>