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.

[Tongyao]

I encountered the same problem using 2026a. I attached an example script generated by AI

The pdf I generated has an aliasing line, and does not look sharp when zoomed in. It looks like a compressed raster image. The figure I generated in 2024 did not have this problem.

% 1. Create a synthetic bathymetry dataset (island with a surrounding seabed)
[X, Y] = meshgrid(linspace(-10, 10, 80), linspace(-10, 10, 80));
Z = 1500 * exp(-(X.^2 + Y.^2)/15) - 3000; % Depth from -3000m up to +1500m (island)

lon = X(:);
lat = Y(:);
bathy = [lon, lat, Z(:)];

% 2. Generate quad face connectivity matrix (nv) for the grid
[m, n] = size(X);
[i, j] = meshgrid(1:m-1, 1:n-1);
v1 = (j-1)*m + i;
v2 = j*m + i;
v3 = j*m + i + 1;
v4 = (j-1)*m + i + 1;
nv = [v1(:), v2(:), v3(:), v4(:)];

% 3. Create vector-friendly figure
fig = figure('Units', 'pixels', 'Position', [100, 100, 800, 600]);
ax = axes('Parent', fig);

% Plot bathymetry using your patch snippet
patch('Faces', nv, 'Vertices', [lon lat], ...
    'FaceVertexCData', bathy(:, 3), 'FaceColor', 'interp', 'EdgeColor', 'None');

% Standard bathymetry styling
colormap(ax, "parula"); % Or 'parula' / 'turbo' if ocean is unavailable
cb = colorbar(ax);
cb.Label.String = 'Elevation / Depth (m)';
xlabel(ax, 'Longitude (\circ)');
ylabel(ax, 'Latitude (\circ)');
title(ax, 'Synthetic Bathymetry Plot');
axis(ax, 'equal', 'tight');
grid(ax, 'on');

% 4. Export to Vector PDF
% Note: 'ContentType', 'vector' forces vector output rather than a raster image
exportgraphics(fig, 'test_bathymetry_plot.pdf', 'ContentType', 'vector');
disp('Successfully saved vector PDF to bathymetry_plot.pdf');

Edit:

Even generating an eps file and open with GIMP still have the problem

I am using MacOS, M1 chip

Edit2:

I tested on a university HPC server with maltab 2024b and 2025b, and the figures were great. They did not reproduce the same problem. I wonder if it coulde be a rendering problem on my laptop

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().