R2025a exportgraphics new behavior for PDF export

I use to export figure to PDF using the following code :

exportgraphics(fig, [ savepath 'fig_name.pdf'], 'ContentType', 'vector');

It contains both plots and imagesc in subplots.

In Matlab R2024b, the exported PDF would look smooth even zooming in -> vector graphic confirmed. Or good enough let's say: I've heard that imagesc figures can't be vectorized in a proper way anyway.

In Matlab R2025a, the plots are ok, the imagesc are very blured, even if I specify dpi = 600 in the exportgraphic function.

So I'm guessing the behaviour of that function have changed.

Anyone has any input about this ?

How can I have the same result as in R2024b in R2025a is my question.

[Matt J]

We cannot verify what you claim without the figure.

[dpb]

The R2025a release notes don't mention a change in exportgraphics that would seem to matter, but there were changes so there could have been unintended consequences introduced.

As @Matt J notes, it would be best to post the figure so others could test...

[Romain Lance]

What you would see on the figure is basically what I described earlier in this post.

I don't understand why you would like to verify an image in a .pdf is blurred, yet I can provide the files, if you think this is important. I'll send those once I have access to this particular computer it is on.

Also, as guidelines just take any randomly generated dat and do: fig = figure; subplot(); plot(); subplot;() imagesc(); exportgraphics(fig, [ savepath 'fig_name.pdf'], 'ContentType', 'vector');

Really easy to reproduce ;)

I've read the R2025a release note before posting and saw the changes as you did @dpb, that's actually the reason why I went to this forum in the first place.

[dpb]

"...ust take any randomly generated dat..."

We don't know that it isn't specific to the given figure or machine/system is why...

Submit this to Mathworks as an official support request/bug at <Product Support Page>

[Romain Lance]

To test specifity of the figure, I tried different data on the problematic imagesc. Which I ruled out since issue appeared regardeless of the data used.

For what can be system specific, the way to rule it out would be that someone test it on his machine with the procedure given in my last comment. Unless the procedure I gave is missing some points to be followed consistently...

[dpb]

You didn't provide such information initially, and it's generally simpler/more convenient to provide all needed rather than require the volunteer respondents to create on their own which may or may not actually create the same issues.

I have not installed recent releases because seem to be so many issues so can't check here...somebody with current release may come by.

Just go ahead and submit the bug report/support request...

[Romain Lance]

Simpler than creating a matrix of random values is pretty hard to pull off.

Also the data I used are confidential for now.

Thanks for the advice on posting the bug support request and for your time.

Answer 1

[Isha]

Hello,

This issue might seemed be related to this known bug in MATLAB R2025a: https://www.mathworks.com/support/bugreports/details/3668256

Currently there is no workaround according to the page.

Hope this helps.

[Romain Lance]

I'll wait for updates and export with older versions then. Thanks Isha!

[Stephan]

With R2025A/B, our exportgraphics() for vectorized content on Linux only works for .eps files (.svg/.pdf led to visual artefacts, broken text objects --eg each character as single text object, or other problems.) For mixed rasterized & vectorized content as with imagesc/surf/pcolor/etc, the Linux/X11 workaround we have is ugly, but it works:

1. get figure ready as normal in matlab.

2. note current screen dpi ("xdpyinfo | grep resolution")

3. set X11 dpi to print quality eg: "xrandr --dpi 600" (yes, figures will look ridiculous with huge fonts/layout when displayed on screen, but they will print fine)

4. open a new matlab and make your figure, then:

exportgraphics(gcf,'blah.eps','ContentType','vector','Width',w,'Height',h)

5. close matlab, set xrandr --dpi back to original.

The basic problem is that matlab only rasterizes at screen DPI, so the only current workaround we have is to temporarily change the screen DPI to something publishers will accept for vectorized content. We had no success with print()/saveas().