Problem with 'Patch' graphics in 2014b - Splits in two along diagonal

I'm using 'Patch' to replace the boxes in box plots to change the colour etc. Code is:

h = findobj(gca,'Tag','Box');
for x=1:length(h)
   boxShade=patch(get(h(x),'XData'),get(h(x),'YData'), colours(x,:), 'linestyle', 'none');
   uistack(boxShade,'bottom');
end
delete(h);

This worked fine until I updated to 2014b where now the Patches appear to split in two along the diagonal, with the median in front of one half and behind the other. Example cut from exported pdf:

I am using the painters renderer as I'm outputting vector pdfs. Any ideas? I've seen some other talk that it's a bug from intersecting lines in a patch but there are no intersections here I believe as it's just a simple rectangle?

Any help greatly appreciated! David

[Rainer]

Experiencing the exactly the same problem with MATLAB R2015b. Any suugestions?

Answer 1

[Mike Garrity]

The warning about DrawMode is trying to point you at the issue I described here:

http://blogs.mathworks.com/graphics/2014/11/04/sortmethod/

I'm not sure why you're getting that message when you call the axes function. Is it possible that you have something in your startup like this?

set(0,'DefaultAxesDrawMode','normal')

If you read that blog post, you'll see that choosing the wrong value for SortMethod can result in artifacts that are similar to what you're seeing, so it would probably be a good idea to track down where that warning is coming from.

[David]

Thanks for this Mike.

I did have that line in my startup.m file. Removing it has stopped the errors and also made the median lines appear consistently where they should. Thank you!

The only remaining problem I have is the ability to see the patch triangles on the pdf output. As Doug said above, they can be removed by altering the viewer's smoothing settings (Mac Preview in my case); however, this is to the general detriment of viewing pdfs. And also does not help when sharing/publishing work as the default is on.

As they were fine previously, before r2014b, I can't help feeling something is amiss? (just to be sure, I'm currently downloading r2014a before the graphics change to check that it did indeed work as I say!)

[Mike Garrity]

The change in 14b is that we've become a lot more aggressive about breaking polygons up. The reason for that is that we also ran into a lot of problems with downstream tools when they encountered the giant, complex polygons that MATLAB users often create. As you can see, we got a bit carried away with that. It really isn't necessary to break up things like the quad in a box plot. We're going to be moving back towards making the polygons we generate a bit more complex than this, without going all the way back to the old extreme of just putting whatever polygon you create directly into the output file.

[David]

Thanks, I can now understand what's going on!

I assume this isn't going to happen until r2015a?

[Ian Ellwood]

While it's nice to know what's going on, this pretty much breaks the patch/fill functions for any application involving eps or pdf output. It would be very helpful to have an update ASAP that fixes this. I am currently forced to find an older version of MATLAB to make plots with sold areas in them (a large percent of the plots I make).

Additionally, I don't understand why you would triangulate any polygons at all, even for complex polygons. Let the user decide to do this themselves if they want. Getting triangulation right without cracking is extremely difficult and should be left to the pdf renderer.

This new problem seems to be similar to the bizarre choices MATLAB makes when trying to render a plot at a resolution below the resolution of the data set, which often produces strange jagged eps output. I'm not sure what the philosophy of the graphics department is, but, in general, I want my eps/pdf/svg output to be as close as possible to the graphics primitives that I am plotting with no modifications.

[Ben Ward]

I second this. I really hope an option to get rid of the subdivisions can be introduced, because the way it is now creates a problem for people using software such as Illustrator. I am seeing a 25-fold increase in my .eps file sizes, to the point that they are completely intractable in Illustrator.

Dividing a vector patch into a discrete number of uniform triangles completely defeats the point of saving a vector image, as it is now essentially a (very poor and inefficient) bitmap.

[Ryan Webb]

Has there been any progress on this? It is absolutely insane that you have broken the ability to export patch objects to .eps and .pdf, without providing a fix...

[Jaime Palter]

It's November 24, 2015, I'm using R2015a, and the problem of the broken polygons and HUGE file size for vector graphics (e.g. eps with -painters renderer) seems unfixed. Has there been any progress on this front? For my purposes, the increased file size is a deal-breaker when trying to produce publication-quality graphics with (e.g.) multiple panels with different colorbars.

[Jonathan Lauderdale]

This remains a big problem - just updated from 2014a to 2016a and the vector graphics look terrible! "contourf" plots are no longer nice patch objects, or even patches broken into a small number of smaller objects, but many many abutting rectangles in a brickwork pattern with the dreaded antialiased white borders (see screenshots below, same code, same antialias options in preview, or the attached pdfs). I have come across this before using other visualization and analysis software and in my experience, "downstream tools" like Inkscape have a much harder time handling the vastly increased number of simple objects, than a small number of complex objects. Please, please provide an option to produce single patches in vector output!

2016a:

2014a:

PS - one thing that is fixed is the colorbar now looks the same in the figure window and the output, although they are still embedded raster objects and, bizarrely, the 2016a version also has a dividing white border that runs from bottom left to top right!

Answer 2

[Steve Hansen]

Just checked R2015b an this significant problem remains.

For me and my research, you guys have broken one of the best parts about Matlab, quality vectorized figures. What is the point of having vectorized graphics if you are just going to chop up polygons into a large number of tessellated triangles?

I use contourf regularly to produce publication quality figures and the new graphics engine has made Matlab completely unusable for this purpose. Thus, this 'upgrade' represents a large step backwards for me.

My suggestion to anyone who needs a 'workaround' is to downgrade to Matlab R2014a until they fix this issue.

Here is a simple illustration of the problem:

load('penny.mat')
figure
contourf(P) 
colorbar
colormap copper
set(gca,'Ydir','reverse')
print(gcf,'penny.pdf','-dpdf')

I have attached the results from R2014a, R2015b and R2015b using the 'opengl' print option.

The individual pdf files sizes are, R2014a : 23 KB, R2015b : 245 KB, R2015b openGL : 77 KB

The R2015b version is an order of magnitude larger in file size due to the tessellation and looks terrible. The R2015b openGL version is better but is a raster image which defeats the utility of vectorized graphics. Only the R2014a result is usable.

[Preetish Kakkar]

I think this has been fixed in 17b, can you please check and confirm?

[Mohsin Shah]

I still have this problem with 2016a. Attached is an image taken from my research article. I wonder how to solve this issue.

[Preetish Kakkar]

Can you provide sample matlab code that was used to produce this image?

Answer 3

[Chris Churchill]

Claiming that this is a bug with pdf viewers is really passing the buck. If I am creating vector art of a patch that is all the same color and one continuous area (even a perfect square!), I expect the same thing to be drawn in the vector output. Splitting into triangles not only breaks anti-aliasing, but it makes it impossible to edit in post-processing, which is why we use vector art in the first place. This bug is costing me many hours of grief in creating figures for publication. I can technically fix this in Illustrator by selecting all the patch triangles that should be one, and then merging them, but that doesn't work when there are thousands of triangles.

Mathworks should really automate this "merge" function by merging all polygons with the same color- that will be at least a step in the right direction on this problem.

Answer 4

[Tami Lieberman]

I am having the same issue in MATLAB 2016a, that doesn't show up when I run the same scripts in 2013a. This is unacceptable.

Answer 5

[Jody Klymak]

I truly feel mathwork has made the wrong decision here, and it is losing them customers. If a polygon is so complicated that it cannot be rendered well by a pdf viewer, then the user should have the option to rasterize the part of the figure that is too complicated, and should save it as an embedded image in the pdf. This is what python's matplotlib does. The PDFs produced by matplotlib combine raster objects and vector objects. As others have said, breaking up polygons defeats the purpose of rendering in polygons in the first place.

Answer 6

[Simon]

Breaking up complex polygons into triangles is not just a EPS or PDF viewer antialiasing problem. It also results in 6x larger file sizes where filling constitutes most of the expense, e.g. area plots like Gunnar's. For scientific or engineering data, this can increase the file size from manageable to unmanageable.

I'm dissatisfied with my workaround of having to join the ends of lines into patch/area polygons with Illustrator.

Jody Klymak wisely suggests MATLAB rasterize complex parts of the figure. In this case it could just be the filling that's rasterized.

Answer 7

[fromLondon]

+1 This is unacceptable. Virtually every Matlab user I know has a routine of exporting figures and then polishing them in Illustrator. Thanks to every area being dozens or hundreds of triangles now, this becomes an absolute chore. Please fix this!

Answer 8

[Rob Campbell]

This issue has been present for a decade at least. Disappointing, it must be said.

[Rob Campbell]

I notice now that the problem might have become worse. I recently ran some old code that produced plots which didn't exhibit these artifacts two or three years ago but it now does.

[Jesse Knight]

I have the same problem.

[Preetish Kakkar]

Hi Rob, can you provide us with examples that got worse? We would be more than happy to help you and provide solutions.

Answer 9

[Doug Hull]

The file we are creating in MATLAB is correct and what you are seeing is a bug in Adobe Reader, refer to Stata’s description of the issue: http://www.stata.com/support/faqs/graphics/line-artifacts-in-filled-contour-plot/

The edges of the triangles are visible because the program used to display the file, such as Ghostview, is attempting to "smooth" the edges of the triangles where they meet.

An easy way to see this is to print the same figure to a PDF file and then open it in Acrobat Reader. The default preference setting is for Reader to "smooth line art". If you uncheck this option the figure looks fine.

To change the option in Acrobat Reader go to Edit->Preferences, select the Page Display category; you'll find it in the Rendering section

[David]

Thanks for your reply Doug.

I don't think this is the source. The problem is visible directly in the Matlab figure window before export. The 'triangles' are not discretely visible but you can see when the red median line is partially or completely obscured by them. Screen grab of the Matlab figure window below:

If you zoom in and out on the axes, the red median line randomly appears/disappears/half obscured by a patch 'triangle'.

As I said, this script worked absolutely fine on this machine before I updated to R2014b with its new graphics (old version was R2013A maybe?).

One possibly related thing I do keep getting is the warning below any time I make an axes, e.g.

>> figure
>> axes
Warning: The DrawMode property will be removed in a future release. Use the
SortMethod property instead.

As these are inbuilt functions, why are they not inline with the latest methods?

[Ian Ellwood]

Re: Doug Hall's answer, what MATLAB is producing is absolutely not correct eps or pdf output. Both eps and pdf have primitives designed for arbitrary polygons and MATLAB, instead of outputting these polygons, is breaking them up into triangles. This is what creates the "cracking" that the OP is complaining about. It is a hard computational problem for the eps/pdf renderer to try and figure out which triangles being rendered are actually supposed to be drawn as a single polygon and it typically won't bother. Hence you will usually see thin white lines crisscrossing the image (in a very platform dependent manner). The suggestion that you should "fix" this problem by turning off "smooth line art" is not sensible as the image quality will suffer greatly. (Not to mention how ridiculous it is to tell this to your collaborators when you send them an image). I realize that there are going to be bugs as MATLAB's graphics renderer is updated to reflect things that have been standard practice for the last 20 years everywhere else, but not being able to produce a scalable vector graphic of a plot with a filled area is a major issue and needs to be fixed.

[Benedetto Barone]

I recently moved to R2014b, and this represents a major issue for the kind of graphics that I produce with MATLAB. For future software versions, please consider having an option to output entire polygons and not triangles, as in previous MATLAB versions. From my experience, filled contour graphics are often used in the earth sciences, and having to use a raster format is not an appealing choice.

[Mike Garrity]

In R2015a, we've moved the needle a bit back towards more complex polygons. Not as far as in 14a or earlier, but it should help some cases.

For example, here's what Adobe Reader makes of an area printed to PDF from R2014b:

And here's what it did with the same area chart printed from R2015a:

However, there are still cases where we break up polygons which we would not have in R2014a or earlier. The reason for that is that in addition to this antialiasing bug, we've also seen applications which read PDF files struggle with the kind of complex polygons that are easy to create in MATLAB.

[Benedetto Barone]

Thanks for the update, Mike. I just installed 2015a and did a test contourf plot. Unfortunately this new Matlab version produces very similar vectorial figures, in my case. Instead of triangles the polygons seem to be subdivided in rectangles, but this doesn't help much. My vectorial graphics are still filled with white lines.

[Mike Garrity]

Yes, contourf tends to create polygons which are too complex for many applications, so we can't just put the whole polygon into the PDF file. We need to split it up.

We'll keep fiddling with exactly how we split it up, but there isn't a perfect solution when some PDF readers can't handle multiple abutting polygons correctly, and some PDF readers can't handle single polygons correctly.

[Benedetto Barone]

Just to give you an example, here is a shapshot of an eps that I produced with contourf in Matlab 2015a.

[Gunnar]

Are there any plans to fix this problem in a future version? I can't expect colleagues to turn off their graphics smoothing for my figures. This is how a patch looks like when printed to pdf.

[Mr T]

Does anyone have a viable workaround aside from opening in 2014a? I'm having issues with patchy patches too.

[Benedetto Barone]

Hi again, has there been any change in Matlab 2015b regarding this problem?

Answer 10

[Dene Farrell]

[a workaround: fix_matlab_vector_graphics]

I think that this issue has gotten confused because there are three distinctly different yet conflated issues with the vector graphics from Matlab.

1. Objects that should be single objects are fractured into many smaller objects.
2. Extraneous Cropping Paths are sometimes added to non-vector and/or vector objects.
3. Various anti-aliasing behaviors in different document viewers behave differently, which is beyond Mathwork's domain of what they can address, but they certainly can fix the first two problems.

I think it would be a start if they would at least acknowledge that 1 and 2 are real problems that arise from their own product, and they have nothing to do with adobe as you can see them in other viewers like Inkscape and Preview, in fact no viewer exists that does not make this output look weird by default.

Even if these vector graphics files looked nice in some given viewer, they are still a nightmare to edit due to all the fragmentation of the objects.

In the meantime...

Here is a hack fix that uses Illustrator programmatically to fix Matlab's output by uniting fractured paths of the same color. I don't think there is anyway to fully deal with this problem from outside of Mathworks core code.

fix_matlab_vector_graphics

Essentially it does the same thing that a previously posted fix ( fix_matlab_eps ) does, except it works with Illustrator instead of Inkscape. And for me the Illustrator fix works better, the objects are grouped together properly after it finishes running.

[Nathan GREINER]

Your fix_matlab_pdfs__jsx_plus_ai package worked perfectly for me. I used it to merge the myriad of patches resulting from a `fill` command. Thank you very much !

Answer 11

[Vedrana Dahl]

I have found following helpful: https://github.com/Conclusio/matlab-epsclean

[Jan Pecka]

Same here, works great. Both with print() and hgexport().

Answer 12

[Walter Roberson]

I happened to notice the following bug report https://www.mathworks.com/support/bugreports/1174438 marked as fixed for R2017b

"Unexpected fine lines across graphics in PDF, PS, EPS and SVG files"

" If you save a figure with MATLAB graphics to a PDF, PS, EPS, or SVG file and then open the saved file in a viewer application (such as Adobe Reader, GSView, or a web browser), unexpected fine lines can appear across filled areas. Zooming into the graphics does not eliminate the lines.

These lines are a side effect of anti-aliasing algorithms used by some viewer applications when displaying the shapes that MATLAB graphics creates in the files. The lines do not appear if you print the file to a paper copy because printers do not use anti-aliasing. "

" The current fix removes white lines that appear across any 2-D polygon object or geometry that is a single color. It is possible that the white lines still appear across other objects, such as a 2-D polygonal with textures or color gradients."

Could some of the people who have been affected by this problem test to see if this resolved the issue for their use case?

[Jast]

It mostly fixed the problem in the contour plot (small fine lines remain),but some issues remain in a colorbar. See picture attached.

[Preetish Kakkar]

Hi Jast, I don't see any attached pics in your link, can you please share code that is still showing up whitelines?

Answer 13

[Saul]

Patches being broken up and rendered as triangles (as described by Mike Garrity) wouldn't necessarily be a problem except that PDF viewer renderers (Acrobat, Mac Preview, etc) tend to produce an thin edge artifact between perfectly abutting triangles when in anti-aliased (smooth text and line art) mode (as described by Doug Hull). You can tell this is a PDF renderer artifact because the on-screen thickness of the edge artifact doesn't increase as you zoom into the PDF.

Turning off anti-aliasing isn't a practical solution since it is an end user setting, and it will make just about every other PDF look horrible.

The hacky solution is to add a tiny offset to your patch coordinates so there is a small bit of overlap between triangles. You can make it so small as to be imperceptible but it will eliminate the renderer artifact.

Ultimately this is a PDF renderer bug that Adobe and other PDF rendering engines should fix.

[MikaJ]

I have a similar problem with eps output of the maps generated by geoshow in 2014b - polygons are split to triangles. This is not only an aesthetic issue - it makes postprocessing of the maps with something like Adobe Illustrator next to impossible. In geoshow call, DisplayType is set to polygon. I'd expect polygons to appear in vector output as they are defined in the shapefile, so as to be able to select them as objects in the postprocessing phase.

Answer 14

[Dhruv Balwada]

I am having similar problems even on matlab 2015a.

Its not only the white lines but also the contour labels are not visible. If you play close attention you can see that there are contour labels but they are not visible. The problem is not resolved by removing the smoothing feature from PDF viewers.

Does anyone know a good workaround? Would be highly appreciated.

Answer 15

[Silja Heilmann]

I am having a similar problem though not in the context of a complex polygon - I see white lines along the diagonal of some but not all images when saved as eps in Matlab 2015a and imported into illustrator (see screen shot from illustrator).

Mike Garrity writes: "Yes, contourf tends to create polygons which are too complex for many applications, so we can't just put the whole polygon into the PDF file. We need to split it up." - I get that - but how come a square image or a square colorbar gets split in to two triangles?

Answer 16

[Ilja Maljutenko]

Following are figures made using two different versions of Matlab and Python of same peaks data.

To illustrate the differences the .eps files are decomposed element by element using Inkscape (same version).

Matlab R2012b:

Matlab R2015: (note lots of white on the figure and ticks under the patches)

Python matplotlib:

I hope that forwarding this issue to viewer software can now be excluded.

For those who urgently need to fix eps figures, i can recommend trying this python software (which relies on Inkscape ).

fix_matlab_eps

It simply takes what Matlab have produced in eps file and merges it into one.

[Bryan]

Agreed. If matplotlib in python can do it properly for free, then shouldn't paying Matlab users have at least the same functionality?

Also, on a related note, as was mentioned upthread, we can't embed raster images into a PDF in Matlab, as can be done in matplotlib. So I end up saving the linework by itself as a PDF, and the raster stuff by itself as PNG, and then combining the two in Illustrator. Takes me about 30 minutes each time. Then my supervisor asks for the plots to be remade. Or I need to make a loop of 100 plots...

Come on guys, what are we paying for.

[Preetish Kakkar]

Hi Bryan, sorry you are having trouble with this. I think this is fixed in 17b, can you please share any cases (along with sample script) where its still reproducible?

Answer 17

[Matthew Arthington]

In case this may be a suitable temporary workaround for anyone else using Windows: I implemented an automated solution for myself. I save a figure in my current Matlab instance (2016b) as a fig file, then call a deployed function, compiled in Matlab 2013b, to open the figure file, save it as a PDF and close it again. Whilst it takes a few seconds to complete, it does result in a good rendering of patch objects in the final PDF, and reduces the need for further manual intervention. The function code to be compiled by calling

mcc -mv loadFigureIn2013bAndSaveAsPDF

in 2013b was as follows:

function loadFigureIn2013bAndSaveAsPDF(figureFile, filenameToSavePDF)
%This function is designed to only run in Matlab 2013b
v=ver('matlab');
assert(strcmpi(v.Release(2:end-1),'R2013b'),'loadFigureIn2013bAndSaveAsPDF must be run in Matlab 2013b');

close all
open(figureFile);
hFig=gcf;
adjustpdfpage(hFig);
saveas(hFig,filenameToSavePDF,'pdf');
close all
clear
end

I call the file from my newer Matlab instance using:

directory='C:\installPathOfEXE\';
myFigFileName='myFigFile.fig';
myPDFFileName='myPDFFile.pdf';
s=system(['"' directory 'loadFigureIn2013bAndSaveAsPDF.exe" "' myFigFileName '" "' myPDFFileName '"']);

One final note, I had to copy a tbb.dll file from C:\Program Files\MATLAB\R2013b\bin\win64 into the directory where I keep the loadFigureIn2013bAndSaveAsPDF.exe file.

Answer 18

[Hiroki Watanabe]

The problem still persists on the 2016b release. I really hope they will fix this on the next release.

[Preetish Kakkar]

I think this has been fixed in 17b, Please confirm if you still see the problem in 17b along with sample script.

Answer 19

[Jan]

See https://de.mathworks.com/matlabcentral/answers/15388-artifacts-in-figures-exported-as-pdf-from-matlab: When the renderer of e.g. Acrobat Reader creates these light lines, there is no chance to "fix" this in Matlab.

[Bas-Jan Zandt]

Yes, but rather than having to fix the problem in Inkscape, Illustrator, Adobe reader and Preview for me and all my colleagues, I'd prefer to have the option to use the rendering method of the older Matlab versions that did not give rise to this problem.

[Walter Roberson]

.. that did not give rise to the problem as obviously, but which triggered other problems more obviously.

Answer 20

[Peter O]

Has this issue been addressed for 2017a? I see it has acquired a ticket as of last year: https://www.mathworks.com/support/bugreports/1174438

I don't think the workaround listed is particularly effective because while it addresses the print problem, the major use case isn't addressed: I suspect most people are reading PDFs on their screens, particularly during the peer review and research processes. And this might be a case where the "right" way to do it isn't necessarily the "correct" one. Has Mathworks talked to Adobe about the render bug?

It would be nice to have control over the triangulation strategy during the PDF render (i.e. force it to treat a patch object as a single unit with no tessellation, consequences be damned!). If I'm doing further editing in Illustrator, for instance, I don't want to recombine all of those triangles.

I'm spitballing here, but perhaps Mathworks could add another field onto affected r2017+ graphics that allows the user to control this, like

h.ObjectRendering = {'auto','unified','split'}

where "auto" does some form of hit-test on the image to find if there are intersections and maybe a heuristic on its complexity and applies the fragmentation as-needed, "unified" spits out a single closed-path, and "split" uses the current approach of triangulating everything.

[Walter Roberson]

Information about R2017a Prerelease is not publicly available. (I am under non disclosure so I cannot say what I know about the situation.)

[Jacob Wenegrat]

Now that R2017 is available, is there any update on the status of this issue? I understand the background on why this problem exists, but the existing workaround (change reader settings) is a non-starter for those of us who use Matlab to make publication ready graphics. Thank you.

[Walter Roberson]

There is no documented change in the situation in R2017a. :(

[Rob Campbell]

Apparently a fix may be in the pipeline in 2017b.

[Jesse Knight]

Working with a trial version of R2017b I can confirm this is still a problem. Looking forward to migrating my research to python ...

[Preetish Kakkar]

Hi Jesse, can you provide an example or a sample script where you still see the problem? We do expect 2d plots such as contours to be fixed in 17b.

Answer 21

[Nino]

I use Plot2Latex to export my figures as svg and then integrate it in Latex. Looking at the svg from the "saveas" function used in Plot2Latex, I found that the patch objects are written like

....bliblablub.... style="fill:rgb(53,48,147); stroke:none;

I solved the issue by replacing all the "none" to the corresponding rgb color by opening the svg directly in MATLAB and the replacing can be scripted. It solved the problem for me. I doubt that it is general, though.

(offtopic, one can also remove the annoying white background of exported svgs in a similar way.)

Answer 22

[GK15]

Hello All,

I am experinencing similar issue whiel trying to export figure on Microsoft word 2017. I have Matlab 2015b on my computer. I didnt run into this issue last year when I had office 2010.

Does anyone know what is a potential fix? How do I get rid of vertical white fine lines which is not part of my data?

Answer 23

[Joel]

If everything else fails, Adobe Acrobat Pro in combination with Adobe Illustrator (for example) may help. Here is how.

1. In Adobe Acrobat Pro, open the pdf figure or the pdf document in which the figure to be fixed is embedded.
2. Select 'Content Editing', 'Edit Text and Images'
3. Select the chopped up image (left click and drag to select all the patches at once, or shift and left click on individual patches if appropriate)
4. Right click, select 'Edit Using' and look for Illustrator
5. In Illustrator, select all the patches, then right click and select 'Release Clipping Mask'. If instead you see 'Make Clipping Mask', then you might have grabbed something else besides patches, such as a label, a tick or an axis.
6. Select 'File', then 'Save'.
7. The figure in Adobe Acrobat Pro is now fixed, hopefully. Save it.
8. Breathe.