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

Forcing painters renderer breaks images #262

Open
durack1 opened this issue Nov 29, 2018 · 6 comments
Open

Forcing painters renderer breaks images #262

durack1 opened this issue Nov 29, 2018 · 6 comments

Comments

@durack1
Copy link

durack1 commented Nov 29, 2018

I pulled the latest version (26eb699) of export_fig yesterday, so this should be directly reproducible.

This issue replicates #107 (superscripts in figure axes), but also goes further than this as the output from the -opengl vs -painters renderer option yields very different (and incorrect) output. This can be most easily described with examples.

So I generate a figure which looks fine on the screen, and using -opengl or -painters I get the following, for completeness the command is (with either renderer specified):

export_fig([out_dir,datestr(now,'yymmdd'),'_Fig',fignum],'-eps','-opengl')

So the OPENGL output looks like
181128_fig1-opengl
And the PAINTERS output looks broken, with the fill seeming to be mixed across layers, like
181128_fig1-painters

A similar issue also occurs with another figure, so

OPENGL
181128_fig5-opengl
PAINTERS with text missing along with lines that should be bolded not in the Pacific and Indian oceans
181128_fig5-painters

Is this an export_fig issue, or matlab?

For completeness:

MATLAB Version: 9.5.0.944444 (R2018b)
Operating System: Linux 2.6.32-754.3.5.el6.x86_64 #1 SMP Thu Aug 9 11:56:22 EDT 2018 x86_64
Java Version: Java 1.8.0_152-b16 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode
Export_fig Version: current master (26eb699)
@altmany
Copy link
Owner

altmany commented Nov 30, 2018

I believe that the problem is due to internal bug(s) in Matlab's builtin print function (which is used by export_fig). In order to verify this, please run the following command and check whether you see the same problems in the resulting test.eps file:

print(gcf, '-loose', '-opengl', '-r864', '-depsc2', 'test.eps')

If you see the same problems, then you should report these to Mathworks ([email protected]).
If you do NOT see the problems, then this means it's a problem in export_fig - in this case I may be able to fix it.

Let me know what happens.

@durack1
Copy link
Author

durack1 commented Nov 30, 2018

@altmany thanks for that, so I did run this through using the command above (with a tweak to the filename) and got this:
181130_fig1-test

So it does indeed appear to be an issue with export_fig

@durack1
Copy link
Author

durack1 commented Nov 30, 2018

@altmany and for completeness, this is the second figure which also checks out fine.. I do note the file size has jumped considerably though from 6.8 to 25.5Mb.
181130_fig5-test

@altmany
Copy link
Owner

altmany commented Dec 4, 2018

Email me the *.fig file for the figure with the charts and I will investigate - altmany (at) gmail

@durack1
Copy link
Author

durack1 commented Dec 24, 2018

@altmany thanks for this, I have sent these through via email. Happy holidays!

@altmany
Copy link
Owner

altmany commented Jan 2, 2019

@durack1 - I ran your figures through Matlab's builtin print command and the resulting EPS files show the same problems as the ones that you reported:

print(gcf, '-loose', '-opengl',   '-r864', '-depsc2', 'test-opengl.eps')    % ok
print(gcf, '-loose', '-painters', '-r864', '-depsc2', 'test-painters.eps')  % not ok

This proves that it's a problem with Matlab's builtin print command, and not with export_fig. I suggest that you report this to Mathworks ([email protected]).

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

No branches or pull requests

2 participants