Save a figure to PDF or EPS with non-standard fonts

If I generate a figure using some fancy fonts, for example like this:

   plot(rand(3));
   set(gca, 'FontName', 'Georgia');
   title('My graph', 'FontName', 'Impact');

then when I export the figure to PDF or EPS using print, e.g.:

   print test.pdf -dpdf

the fonts are changed to Courier. This is because only a small number of fonts are supported when printing using the Postscript or Ghostscript drivers (e.g. when exporting to PDF or EPS files using the painters renderer).

How can I get round this limitation? Ideally I'd like a programmatic solution (i.e. one which doesn't require any user interaction).

Answer 1

[Daniel Shub]

On a Windows machine with a virtual pdf printer (in my case the one that comes with Adobe Acrobat Pro) I can print to a pdf file and the fonts get embedded.

I tried this a few years ago (before there was export_fig). The biggest problem I had, and the one that made me give up, was I couldn't bypass the print dialog box. I always had to provide confirmation. I think there may have also been small changes in the figure and in some cases sections of the figure were replaced with bitmaps.

EDIT:

I can get a little closer. On both Windows and Arch Linux I have a virtual PDF printer installed and named PDF Printer. On Windows it the Adobe Acrobat Pro (or maybe Adobe Distiller printer) on Linux it is the CUPS-PDF printer. On both systems

print '-PPDF Printer' myfilename.pdf

gives the desired result without any user interaction. I think it should be pretty OS independent and consistent across PDF printer type. Integrating it into export_fig may be harder. You will either need the user to supply the name of the PDF printer or a good guess as to what it is called. Guessing the printer name will probably be harder than guessing where Ghost Script is installed.

[Oliver Woodford]

I just sent my example figure to a Bullzip PDF "printer" and it did indeed have the non-standard fonts correctly in it. Nice!

However, as you say, this isn't a programmatic (i.e. non-interactive) solution, because of the print dialog box.

[Daniel Shub]

I bet you can get around it with a java robot, but it would be so ugly ...

[Oliver Woodford]

Interesting update. Thanks. One problem I see with incorporating this approach into export_fig is that you probably lose control over the compression level of bitmaps. There could be others.

[Jan]

You can select the printer using the -Pprinter flag of the PRINT command. There are PDF printers available, which do not need a dialog.

Answer 2

[Juan Guerrero]

Hi, I came up with a solution explained here: http://isa.uniovi.es/~guerrero/FontExample/FontExampleFiles.zip

There are pretty amazing solutions like export_fig but when you only want to obtain a pdf with correct fonts this is simpler. Another advantage is that you are aware of what you are doing, which is an advantage when the Matlab version changes.

Best regards.

[Michael G. Baker]

This is a good work-around for something that Matlab should have fixed long ago.

On Mac El Capitan, I needed to add the "-dNOSAFER" flag to the GhostScript call to prevent GS from crashing due to file permissions (even though I had read/write for the specified file).

Answer 3

[Owen Gebler]

My solution to this problem is to use the open-source image editor Inkscape to convert an SVG plot produced by MATLAB to a PDF file. This can be automated from within a MATLAB script by calling Inkscape via a command prompt with the following command:

        command = strcat('"C:\Program Files\Inkscape\inkscape.exe" ', {' '}, '"', fileToConvert,...
            '.svg" --export-pdf="', fileToConvert, '.pdf" --export-pdf-version=1.5 --export-area-drawing');
        command = string(command);
        [ status, msg ] = system(command); % Run command prompt - return variable to suppress output text

Obviously this is Windows specific, and one should ensure Inkscape has been installed locally, and the path to it is accurate in the command.

Answer 4

[Daniel Shub]

When creating eps and pdf files I include the following check:

  validFontNames = {'AvantGarde'; 'Bookman'; 'Courier'; 'Helvetica'; ...
    'Helvetica-Narrow'; 'NewCenturySchoolBook'; 'Palatino'; ...
    'Symbol'; 'Times'; 'ZapfChancery'; 'ZapfDingbats'};
  htxt = findobj(hfig, '-depth', inf, '-property', 'FontName');
  for itxt = 1:length(htxt)
    errorMsg = ['The font "', get(htxt(itxt), 'FontName'), '" ',...
      'is not supported for pdf output.'];
    if ~any(strcmpi(get(htxt(itxt), 'FontName'), validFontNames))
      warning(errorMsgId, errorMsg, '');
    end
  end

While not a solution, at least it warns me about the font substitution ...

[Alan]

But findobj doesn't find objects whose HandleVisibility is off like xlabel and ylabel.

[Daniel Shub]

You are right. I make the handles of all the children visible at the beginning of the function and return them to the original state at the end.

Answer 5

[Oliver Woodford]

The file exchange submission export_fig now supports font correcting in EPS and PDF files for up to 11 non-standard fonts in a figure. If using croppping, there may be issues to do with corrected fonts being cropped slightly, where they are larger than the substituted font.

[Daniel Shub]

If you show the code snippet you use to replace the fonts, I will vote for you. Then you can see if clean, but limited to 11 fonts, solution is more desirable than my hack with the PDF printer ...