matlab2tikz_acidtest exports not compilable .eps figures

[okomarov]

The figures exported to .eps do not compile with epstopdf and I get just a blank .pdf. I described the problem on http://tex.stackexchange.com/questions/208179/epstopdf-error-undefined-in-uagelevel and sent an email to the epstopdf team. It might be Matlab version dependent.

However, there might be a workaround that sets the figure properties and exports a "cropped" .pdf directly, described on how to get rid of white margin in.html.

[egeerardyn]

A few days ago, I tried out a fix for exporting PDFs directly from MATLAB that I obtained from the MathWorks directly (I have an adapted version in my private repo if you'd want to experiment)

There are some problems with this approach, though:

1. while it copies the whole object, this is not a perfect deep copy. E.g. some properties (especially handles and event handlers) are not copied. For some figure kinds (e.g. bode), this breaks the functionality.
2. I noticed some cases where the produced figure is cropped better than the default, but not perfect (e.g. right axis line missing)
3. We cannot omit the copying, as this function in essence modifies the figure. Since we then revisit the same figure with m2t, the output can very well depend on the changes that have occurred in this conversion. Switching the order of execution doesn't help here, as cleanfigure also changes the figure.

This doesn't give me much confidence in the other approach; since there also quite some other properties are modified. Moreover, it will certainly break for subplots. But this issue is certainly something we have to look into.

Regarding your specific problem: have you tried to manually execute epstopdf from the command line on that EPS file to make sure that whether the problem is the epstopdf executable or LaTeX package?

Attached: script that should give a tightly bounded PDF.

%% (C) THE MATHWORKS (SERVICE REQUEST 01006478)
% Create the plot
figure(1)
plot(1:100)

% Create a copy, which we can modify
figure(2)
compCopy(1, 2)

% Do a normal pdf export
print -dpdf pdf_fullpage.pdf

% Set figure bounds to tight, to save ourselves from a lot of computations
% with margins etc.
ui.style.Bounds = 'tight';
hgexport(gcf, tempname, ui.style, 'applystyle', true);

% Get the image size and copy it into the paper size
image_pos = get(gcf, 'paperposition');
set(gcf, 'papersize', image_pos(3:4))

% Export a cropped figure
print -dpdf pdf_croppedpage.pdf

% Close figure 2
close(2)

%% This script call a function compCopy in order to copy a figure. The compCopy file reads:
% Copies content of figure source to figure dest
function compCopy(op, np)
   ch = get(op, 'children');
   if ~isempty(ch)   
      nh = copyobj(ch,np);
      for k = 1:length(ch)
          compCopy(ch(k),nh(k));
      end
   end
   return  

[nschloe]

@egeerardyn What's the licensing on this code?

[okomarov]

Christian Zietz from the epstopdf team found the issue:

I investigated a little further: It seems that the problem occurs only
with MikTeX epstopdf and only if two things come together:
"%%BoundingBox: (atend)" in the header of the EPS file and Unix-style
line endings, meaning only LF and not CR+LF as it is customary in Windows.
...
However, a quick workaround would be to reencode your EPS files to have
Windows-style line endings.

He suggested to file a bug report with Miktex which I am gonna do. On the other hand I am wondering why print() to .eps on Win machine produces Unix line endings. Maybe it is a bug in the recent Matlab version? Need to investigate that.

So, the solution to the current issue would simply be to convert line endings in the generated .eps file according to the platform.

[egeerardyn]

@nschloe : I have no idea about the exact licensing terms. I think The MathWorks wouldn't mind if we post it here or in any project, as long as we're clear on the origin of the code.

In the original fragment, there is no %% (C) THE MATHWORKS (SERVICE REQUEST 01006478). I added this to make sure everybody is on the same page regarding its origin. Otherwise it's easy enough to copy code from the internet while violating a license. And I cannot find such information in the mail or on the website.

IANAL, but licensing should only be a potential problem if we ship a version with this code. In my personal (and private) branch, I rewrote part of the code, but the working is clearly identical. In the case we do get that approach working, I should inquire about licensing terms.

[okomarov]

@egeerardyn with respect to https://github.com/nschloe/matlab2tikz/issues/370#issuecomment-59932383 I do not understand why we cannot avoid the copy? We can save the old paper size and then set it back after the hgexport.

Otherwise I have a fix that replaces on Win the \n or \r (if any) with \r\n: abef196

[egeerardyn]

@okomarov That's a good idea to test out (I will do that). You're probably right we can avoid it, it's just that I do not trust that hgexport in there. It seems to me that it has some side-effects that are wanted to do the export, but they would be disadvantageous for testing.

[egeerardyn]

I tried it out, most of it looks fine to me ( see ACID test ).
Only cases where something funny happened, I'd say are:

• test cases [30 31] get squished in the MATLAB output (no longer rectangular axes)
• test case 51 doesn't show the plot data (but it's an rlocus plot, so it might come with all kinds of dirty tricks)
• test case 60 both overlayed axes are not treated identically...
• probably not related, but keeping track anyhow: test 89 had a legend at (130,100) (or someting), while the data is below 1. This caused too big numbers in LaTeX which I corrected for manually.

But I didn't find any bad crop location (unlike the original code)

The main code I used for that:

function printPDF(h, filename)
% Prints a figure to PDF from MATLAB
%
% NOTE: this implementation is based on code provided in a MATLAB 
% service request (Case #01006478).

% tight figure bounds: less complicated calculations needed
ui.style.Bounds = 'tight';
hgexport(h, tempname, ui.style, 'applystyle', true);

%% capture old state
papersize = get(h, 'papersize'); 

%% correct positioning
image_pos = get(h, 'paperposition');
set(h, 'papersize', image_pos(3:4));

print(h, '-dpdf',filename,'-r150')

%% restore old state
set(h, 'papersize', papersize);

end

[okomarov]

TMW support confirms that the issue with Unix line endings on Win in print()ed .eps files has been introduced with R2014b. Unless, printing to .pdf is strictly necessary I'd stick with the line endings conversion fix.

Alternatively, https://github.com/ojwoodford/export_fig prints always to .eps first and then manually sets the bounding box with @print2eps\move_bb() (and converts with ghostscript to .pdf, but this is not necessary):

[s, e] = regexp(fstrm, '%%BoundingBox: [\w\s()]*%%');
if numel(s) == 2
    fstrm = fstrm([1:s(1)-1 s(2):e(2)-2 e(1)-1:s(2)-1 e(2)-1:end]);
end

[egeerardyn]

Printing to PDF would reduce the complexity of the rest of the test suite, but it is not necessary per se. You're right that we can include your fix first (and close this issue) and fix the PDF thing later. I reckon you've tested your fix on your computer (as I don't have a Windows computer with R2014b installed)?

[okomarov]

The full acid.pdf is available here: https://www.dropbox.com/s/b7z4vtt695n7xsl/acid.pdf?dl=0
(In case you have time to compare with what you guys get)
I am on Win7 64bit R2014b.