Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hidden failure mode for pdftops when outputting to eps #137

Closed
mpacer opened this issue Apr 6, 2016 · 12 comments
Closed

Hidden failure mode for pdftops when outputting to eps #137

mpacer opened this issue Apr 6, 2016 · 12 comments

Comments

@mpacer
Copy link

@mpacer mpacer commented Apr 6, 2016

This took a while to track down, so I thought I'd put it here. I'm new to this package so I can't really submit a PR without spending more time with it & learning how its structured.

tldr; The Matlab2015b version of libfreetype.6.dylib is masking the system one, breaking eps output.

Use otool -L /usr/local/lib/libfreetype.6.dylib to make sure that your local version is 19.0.0 or greater. And then copy that into the MATLAB location: sudo scp /usr/local/lib/libfreetype.6.dylib /Applications/MATLAB_R2015b.app/bin/maci64/libfreetype.6.dylib. This should fix things for you.

Things to note:

  • This did not raise an error when running -depsc.
  • There is probably a better way to do this by fixing where searching occurs and encouraging the system to continue searching for a system library even when the Matlab one is out of date. That surely is the more robust version. However, that's a much harder fix.

Error & debugging walkthrough:
Thought I'd walk through all the various steps along the way, so that when others search the web for this issue (if it isn't fixed) it has a chance of actually turning up their errors. Also it shows a

So, originally, I got the error saying I didn't have pdftops, and I didn't so I brewed it (I'm on OSX). Or rather I tried brew install xpdf, and was told I needed to first brew tap homebrew/x11, which then gave access to xpdf, making the original brew install xpdf command work.

Ran into issues there with a conflict with poppler, but that was easy enough to solve by unlinking.

However, then I kept getting the error popup inside Matlab. Eventually I got into full debug mode to try to figure it out and needed to set breakpoints many levels deep to find the right system state (i.e., the path_ variable that is passed to check_xpdf_path) after which I ran into the error

check_xpdf_path(path_)

returning "/usr/local/bin/pdftops" -h: Trace/breakpoint trap

Which made no sense to me. Diving into check_xpdf_path I saw that this is the command that was erring: system(sprintf('"%s" -h', path_))

Running that on the matlab command line returned:

dyld: Library not loaded: /usr/local/opt/freetype/lib/libfreetype.6.dylib
  Referenced from: /usr/local/bin/pdftops
  Reason: Incompatible library version: pdftops requires version 19.0.0 or later, but libfreetype.6.dylib provides version 18.0.0
"/usr/local/bin/pdftops" -h: Trace/breakpoint trap

At which point I started writing this issue thinking I'd nearly solved it and wanting to be a good package citizen.

But wait! Little did I know that figuring out what was going on with libreetype was going to be a mess on its own. So I had a lot of difficulty finding any online documentation about libfreetype as one of pdftops's dependencies. And while I was at it… I tried to just brew upgrade freetype I was told it had the newest version…no dice

So the next attempt was to rebuild xquartz to the version that was released in November 2015, presuming that pdftopswas relying on a newer version of the freetype library… I then read through this Automattic/node-canvas#471 set of issues, and didn't have any luck. On both the opt and usr directory libfreetypes when I used otool I was getting

/usr/local/lib/libfreetype.6.dylib:
    /usr/local/opt/freetype/lib/libfreetype.6.dylib (compatibility version 19.0.0, current version 19.3.0)
/opt/X11/lib/libfreetype.6.dylib:
    /opt/X11/lib/libfreetype.6.dylib (compatibility version 19.0.0, current version 19.1.0)

So I was a little befuddled.

And then I looked at that again. Used the sudo find command…and lo and behold, the first return to sudo find / -name libfreetype.6.dylib was:

/Applications/MATLAB_R2015b.app/bin/maci64/libfreetype.6.dylib

suspicious that there might be some kind of masking going on I tried the otool -L /Applications/MATLAB_R2015b.app/bin/maci64/libfreetype.6.dylib line, and yep:

/Applications/MATLAB_R2015b.app/bin/maci64/libfreetype.6.dylib:
    @rpath/libfreetype.6.dylib (compatibility version 18.0.0, current version 18.1.0)

so … it was a matter of copying over the libfreetype.6.dylib file to the Matlab location and it all worked(sudo scp /usr/local/lib/libfreetype.6.dylib /Applications/MATLAB_R2015b.app/bin/maci64/libfreetype.6.dylib). I figured this approach would be better than fighting with Matlab's path search order.

@altmany
Copy link
Owner

@altmany altmany commented Apr 6, 2016

@michaelpacer - thanks for taking the trouble and time to write this detailed description. Mighty nice of you. For the benefit of others who might not stumble on this Github issue webpage, can you think of a way to fix export_fig in any way to solve this problem ?

Alternatively, if you let me know exactly which line croaks in export_fig (or one of its child functions), then I could trap this error and at least inform the user that this might be the cause, linking to here.

Let me know please.

@mpacer
Copy link
Author

@mpacer mpacer commented Apr 6, 2016

So it's not that a line croaks so much as it doesn't send back up the full error, making it even harder to debug, and that error was being hidden inside check_xpdf_path(path_) in the pdftops.m file.

I think it was that the system command gives priority to the Matlab search path, and so when it runs system(sprintf('"%s" -h', path_)) where the path_ = "/usr/local/bin/pdftops" it returns

dyld: Library not loaded: /usr/local/opt/freetype/lib/libfreetype.6.dylib
  Referenced from: /usr/local/bin/pdftops
  Reason: Incompatible library version: pdftops requires version 19.0.0 or later, but libfreetype.6.dylib provides version 18.0.0
"/usr/local/bin/pdftops" -h: Trace/breakpoint trap

except it was not even bothering to load from /usr/local/opt/freetype/lib/libfreetype.6.dylib, and then it hides the first parts of that error…so its twice over confusing.

@mpacer
Copy link
Author

@mpacer mpacer commented Apr 6, 2016

It may just be that you need to catch this error, and instead of piping it through to the

while 1
    errMsg = 'Pdftops not found. Please locate the program, or install xpdf-tools from ';
    url = 'http://foolabs.com/xpdf';
    fprintf(2, '%s\n', [errMsg '<a href="matlab:web(''-browser'',''' url ''');">' url '</a>']);
    ⋮

you tell them that even if they have xpdf and therefore pdftops installed, that they may need to copy over their library to the Matlab version so it will find it.

altmany added a commit that referenced this issue May 1, 2016
…);

improved error presentation;
added sample usage in help section
@altmany
Copy link
Owner

@altmany altmany commented May 1, 2016

done

@niuqun
Copy link

@niuqun niuqun commented Jun 29, 2018

@mpacer Thank you! It works like a charm.

@YaduNa
Copy link

@YaduNa YaduNa commented Nov 29, 2018

Sir, could anyone explain what shall I do if I get error137? I didn't understand what shall I do to avoid it?

@altmany
Copy link
Owner

@altmany altmany commented Nov 30, 2018

@YaduNa - you need to ensure that the libfreetype.6.dylib file in your pdftops folder is copied over to Matlab's folder, replacing Matlab's version For example:

sudo scp /usr/local/lib/libfreetype.6.dylib /Applications/MATLAB_R2016a.app/bin/maci64/libfreetype.6.dylib

@YaduNa
Copy link

@YaduNa YaduNa commented Dec 3, 2018

@Irismoon
Copy link

@Irismoon Irismoon commented Aug 9, 2019

Same as the previous comment. I could not find a libfreetype.6.dylib on Windows machine. Any solution would be helpful to try. Thanks,

@altmany
Copy link
Owner

@altmany altmany commented Aug 9, 2019

@Irismoon - *.dylib is a MacOS file, not a Windows file. You need to install the "Xpdf command line tools" from https://www.xpdfreader.com/download.html

@Irismoon
Copy link

@Irismoon Irismoon commented Aug 9, 2019

@altmany I indeed install the cmd tools. But it still does not work. Cmd tools consists of pdftops.exe. As I said in last post, I have pdftops.exe. But matlab could not find it even if I guide matlab to locate it at the right folder. It just shadow it. Not sure if I need install qt, freetype, zlib, etc. At the bottom of the xpdf download page, it says that xpdf reply on those packages. But the link are directed to linux files.

@emilycoding00
Copy link

@emilycoding00 emilycoding00 commented Oct 21, 2020

@Irismoon did you figure out a solution? I'm also getting the errors.
I downloaded the Xpdf tools, unzipped, moved all files to C:/ProgramFiles/XPDF/ as the install.txt instructed.
Now, I get that "Pdftops utility not found". Did I "install" incorrectly? I appreciate any advice. I'm not familiar with terms like shadow and most of the OPs post is over my head. I just want to get .eps files to work with in adobe illustrator that have proper sizing for dashes, dash_dots.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants