Dotted lines blurred when making eps or pdf from 3-D plot in Matlab

[EProyal]

The 2-D plots look great with the dotted lines. When I try and export a 3-D plot of the same dotted lines, they are blurred. Is there an easy fix to this?

[altmany]

3D plots look ok on my system, but perhaps your specific plot causes OpenGL to fail, which degrades the output. You can check this by running get(gcf,'Renderer') and checking whether it's 'opengl' or not.

If you still see a problem on your end, then please paste a minimal reproducible code sample here with a screenshot showing the problem and reopen this issue.

[EProyal]

I re-created the figure and ran get(gcf,'Renderer') and it is 'opengl'. Attached are the .mat files to create the plot, with the code: fig3D = figure; p0 = plot3(yd/1000,xd/1000,zd/1000,'--k');.

mat_files.zip

Also attached is the .png of the resulting .fig.

Also attached is the resulting pdf image, where the dotted lines turn into solid lines, when using the command, export_fig([figname,'.pdf'],'-transparent'); 3d_dottedlines.pdf

Is there a fix? I'm having this problem with a lot of my plots, and MATLAB's saveas(gcf,figname,'epsc') seems to have issues as well. The plots look fine if I use the same linestyle in 2-d, but when I do a 3-d plot, the resulting eps/pdf doesn't look good.

Thanks!

[altmany]

This is due to an internal Matlab bug: the builtin command saveas(gcf, 'test.pdf') results in the very same behavior. I reported this to MathWorks as a bug that they should fix.

In theory, it should be possible to post-process the interim EPS file that's created, but I am not proficient enough in postscript nor have the necessary PS debuggers that would enable me to develop a programmatic workaround in export_fig. If anyone would care to assist, then it would be my pleasure to incorporate the workaround in the utility.

[altmany]

MathWorks confirmed that this is due to an internal bug, and provided a workaround that I incorporated into the code, so the latest version of export_fig now fixes this problem and the lines appear dashed/dotted as they should, and no longer solid.

However, note that MathWorks said that this workaround "may limit other functionality in plotting such as hidden line/surface removal". At this time I do not fully understand what exactly this means - I'm following up with them on this and when I know more I'll update this thread. This may require a follow-up update to the fix I made in export_fig.

So for now I'm keeping this issue open, but you may consider it as fixed in the latest version of export_fig.

[altmany]

So it seems that the workaround fix (setting the axes' SortMethod to 'ChildOrder') should only be used in certain cases, i.e. when there are no overlapping/hidden graphic elements, otherwise the resulting export would look even worse than before (details). So I've added a check for this case by comparing the visual (onscreen) bitmap export before and after applying the fix, and the fix is only used if it looks exactly the same onscreen. Otherwise, the axes' SortMethod are reverted to their previous value and a warning is issued to the Matlab console to inform the user that they should try to fix the SortMethod manually before exporting.

[transmitterdan]

I know this issue is closed but I suspect there is a new bug. It is possibly only visible in later versions of Matlab. I think the changing of SortMethod schemes (e.g. 'ChildOrder' vs. 'Depth') does not actually update the figure graphics until it needs to be rendered. So in a function like print2eps the test for identical images always returns true. Testing shows that insertion of a drawnow() call causes the graphics to be rendered with the new SortMethod thus making the graphics images properly different. This has corrected a problem for me where it fails to recognize any difference between sorting methods. This below figure shows the change I made to get the code to work as expected.

[durack1]

@transmitterdan thanks for raising this, I have found a similar issue when you hide a canvas window, and only after this is made visible with a set(gcf, 'visible', 'on') are the changes to the figure actually picked up by export_fig. I routinely generate figures in batch mode where I don't want the canvas windows popping up, so this was/is a nasty bug. I have reproduced this on Matlab R2020b, with the latest version of export_fig (git pull on the repo before replicating)

[altmany]

I added the drawnow call inside print2array, which I think is better. Let me know if you still see a problem.