https://bugs.documentfoundation.org/show_bug.cgi?id=67465
--- Comment #15 from Tamas Nagy <tlngy+libreoffice@fastmail.com> ---
(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.
--
You are receiving this mail because:
You are on the CC list for the bug.
Context
- [Bug 67465] EPS rendering: locating pstoedit on Mac a problem · bugzilla-daemon
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.