PDFs containing math fonts cause the following error message in Adobe Acrobat: Cannot extract the embedded font. Some characters may not display or print correctly.
The font seems to be displayed correctly, but apparently it is not correctly embedded.
Additional information
To reproduce this issure, open the PDF created by Matplotlib in Adobe Acrobat, navigate to Document Properties > Fonts > OK. The error message is only displayed if one changes the zoom, switches pages, etc. The error message arises in recent versions of Adobe Acrobat on different operating systems.
The error message arises only for PDFs containing mathematical expressions, while PDFs with regular text cause no error message. However, the issue seems to arise independently of the actual font type and arises for the default font dejavusans and others such as stix.
The issue furthermore arises for the default value of pdf.fonttype being Type 3. When switching to TrueType (causing much larger file sizes), the error message no longer arises.
I tried to get more details by using the Preflight tool from Adobe Acrobat, but unfortunately I could not get any. However, since the error message only arises for certain types of fonts, there seems to be an actual reason.
The error message is significant insofar as it also arises if such a figure is embedded in a larger PDF (e.g. via LaTeX) and therefore presumably affects a whole lot of documents.
As far as I can tell, the figures look fine, but it is hard to tell since I usually use the font Stix 2 while Matplotlib uses the former version and they differ anyway.
According to the document properties shown in Adobe Acrobat (prior to displaying the error message) the font is embedded. Similarly, pdffonts provided by poppler-utils states that the font is embedded:
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
DejaVuSans-Oblique Type 3 Custom yes no no 15 0
It could be a bug in Adobe Acrobat, or e.g., maybe something remotely similar to pull request #1808? Does anybody know a way to truly check the PDF, e.g. via the Preflight tool?
3.5 would instead produce a font subsetted file (with 6 characters in the beginning of font name)..
Reproducing the snippet, the embedded fonts are:
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
GCWXDV+DejaVuSans-Oblique Type 3 Custom yes yes no 15 0
^when pdf.fonttype is 3, and:
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
GCWXDV+DejaVuSans-Oblique CID TrueType Identity-H yes yes yes 15 0
^when pdf.fonttype is 42..
Not sure about the actual bug here, but I'd first try to reproduce it with latest Matplotlib build.. also these PDFs do not really bug other native PDF viewers that I've tried them with, so the Adobe Acrobat bug seems possible.
The issue is still the same: for font type 3 the aforementioned error message arises, which states that the embedded font cannot be extracted (the font now has the name GCWXDV+DejaVuSans-Oblique indicating the subset). No error is shown for TrueType.
I already tried to get more details via the Preflight tool from Adobe Acrobat and from Adobe support, which unfortunately did not work out so far, but I'll try again ...
I think I got some more details via the Preflight tool from Adobe Acrobat Pro: according to Preflight the font is not embedded if Font Type 3 is used, while TrueType fonts are shown to be embedded. In the former case, Preflight therefore tries to embed the font. This procedure is shown to be successful, if the DejaVu Fonts were previously installed on the system.
However, while this procedure truly works for non-math text in DejaVuSans (the font is denoted as Embedded Subset afterwards in the Document Properties), embedding apparently does not work for math text in DejaVuSans-Oblique and Preflight vectorizes the math text.
Unfortunately, this does still not reveal any details. However, in my experience printing companies check PDFs in that respect for instance using Preflight – which renders this issue actually problematic, at least to some extent.
@jklymak
Well, there seems to be a broad hint for some issue, probably caused by Matplotlib's embedding of Type 3 fonts. Unfortunately, since I have no profound knowledge about font embedding or the internal structure of PDFs, I do not know how to further investigate or fix the issue – I can only point it out.
Not emitting an empty font embedding makes sense, but I would push back on adobe and ask if that is actually out of spec or not. If the spec does not forbid it we have found a bug in their tool :)
Knowing what I know now, I would formulate my issue differently: it's actually not just about the error message in Adobe Acrobat (regardless of whether out of spec or not as mentioned by @tacaswell). The issue rather addresses the fact that characters with a code ≥ 256 are not embedded as text in the PDF but as a rendered path.
This has many disadvantages: the file size increases (as mentioned by @jklymak), you can't search for these characters, you can't edit them later, etc. – but as far as I know (and as mentioned by @QuLogic), the standard would allow embedding such characters as text.
Activity
andreas-brugger commented on Nov 29, 2021
Consider the file Test.pdf, which causes the aforementioned error message in Adobe Acrobat.
QuLogic commented on Nov 30, 2021
Please try with 3.5.0
jklymak commented on Nov 30, 2021
I tested on 3.5.0 and the error message still exists. OTOH I'm not clear what it means, if anything..
andreas-brugger commented on Nov 30, 2021
I tried to get more details by using the Preflight tool from Adobe Acrobat, but unfortunately I could not get any. However, since the error message only arises for certain types of fonts, there seems to be an actual reason.
The error message is significant insofar as it also arises if such a figure is embedded in a larger PDF (e.g. via LaTeX) and therefore presumably affects a whole lot of documents.
jklymak commented on Nov 30, 2021
.. but does it have a practical effect, in that the document looks bad? Are the fonts actually missing? I wouldn't rule out an Adobe bug here...
andreas-brugger commented on Nov 30, 2021
As far as I can tell, the figures look fine, but it is hard to tell since I usually use the font Stix 2 while Matplotlib uses the former version and they differ anyway.
According to the document properties shown in Adobe Acrobat (prior to displaying the error message) the font is embedded. Similarly, pdffonts provided by poppler-utils states that the font is embedded:
It could be a bug in Adobe Acrobat, or e.g., maybe something remotely similar to pull request #1808? Does anybody know a way to truly check the PDF, e.g. via the Preflight tool?
aitikgupta commented on Dec 3, 2021
3.5 would instead produce a font subsetted file (with 6 characters in the beginning of font name)..
Reproducing the snippet, the embedded fonts are:
^when pdf.fonttype is 3, and:
^when pdf.fonttype is 42..
Not sure about the actual bug here, but I'd first try to reproduce it with latest Matplotlib build.. also these PDFs do not really bug other native PDF viewers that I've tried them with, so the Adobe Acrobat bug seems possible.
andreas-brugger commented on Dec 5, 2021
Could you please add the two PDFs for Matplotlib 3.5 with font type 3 and TrueType, so I could check whether the error arises?
aitikgupta commented on Dec 9, 2021
@theBruegge here you go:
fonttype3.pdf
fonttype42.pdf
andreas-brugger commented on Dec 21, 2021
Thanks @aitikgupta!
The issue is still the same: for font type 3 the aforementioned error message arises, which states that the embedded font cannot be extracted (the font now has the name GCWXDV+DejaVuSans-Oblique indicating the subset). No error is shown for TrueType.
I already tried to get more details via the Preflight tool from Adobe Acrobat and from Adobe support, which unfortunately did not work out so far, but I'll try again ...
andreas-brugger commented on Dec 22, 2021
I think I got some more details via the Preflight tool from Adobe Acrobat Pro: according to Preflight the font is not embedded if Font Type 3 is used, while TrueType fonts are shown to be embedded. In the former case, Preflight therefore tries to embed the font. This procedure is shown to be successful, if the DejaVu Fonts were previously installed on the system.
However, while this procedure truly works for non-math text in DejaVuSans (the font is denoted as Embedded Subset afterwards in the Document Properties), embedding apparently does not work for math text in DejaVuSans-Oblique and Preflight vectorizes the math text.
Unfortunately, this does still not reveal any details. However, in my experience printing companies check PDFs in that respect for instance using Preflight – which renders this issue actually problematic, at least to some extent.
jklymak commented on Jan 6, 2022
@theBruegge Its not clear to me what action you are suggesting for Matplotlib.
andreas-brugger commented on Jan 10, 2022
@jklymak
Well, there seems to be a broad hint for some issue, probably caused by Matplotlib's embedding of Type 3 fonts. Unfortunately, since I have no profound knowledge about font embedding or the internal structure of PDFs, I do not know how to further investigate or fix the issue – I can only point it out.
7 remaining items
tacaswell commented on Apr 20, 2023
Not emitting an empty font embedding makes sense, but I would push back on adobe and ask if that is actually out of spec or not. If the spec does not forbid it we have found a bug in their tool :)
andreas-brugger commented on Apr 27, 2023
Knowing what I know now, I would formulate my issue differently: it's actually not just about the error message in Adobe Acrobat (regardless of whether out of spec or not as mentioned by @tacaswell). The issue rather addresses the fact that characters with a code ≥ 256 are not embedded as text in the PDF but as a rendered path.
This has many disadvantages: the file size increases (as mentioned by @jklymak), you can't search for these characters, you can't edit them later, etc. – but as far as I know (and as mentioned by @QuLogic), the standard would allow embedding such characters as text.
pdf: Improve text with characters outside embedded font limits
pdf: Improve text with characters outside embedded font limits
pdf: Improve text with characters outside embedded font limits
pdf: Improve text with characters outside embedded font limits
pdf: Improve text with characters outside embedded font limits
pdf: Improve text with characters outside embedded font limits
pdf: Improve text with characters outside embedded font limits
pdf: Improve text with characters outside embedded font limits
pdf: Improve text with characters outside embedded font limits