Created attachment 9235 [details] disdpt.pdf The attached PDF-file disdpt.pdf contains some TimesRoman-fonts. For PDF/A-generation we are using following gs-call to create PDF/A gs -dNOPATCH -dBATCH -o out.pdf -sDEVICE=pdfwrite -dPDFA PDFA_def.ps disdpt.pdf It seems that in the output file the font TimesNewRoman is incorrect embedded. If you open the output file with the AcrobatReader and want to print it, a message box is shown with the following message: Cannot extract the embedded font 'SJBTBN+TimesNewRoman-OneByteIdentityH'. Some characters may not display or print correctly.
The original file is inappropriate for conversion to PDF/A as it contains subset fonts which are illegal in PDF/A. Pdfwrite doesn't throw an error on this (perhaps we should) when creating PDF/A output but continues to process the file. In addition the file contains multiple differently subset fonts with the same name *and* the same subset prefix, which is truly bad practice. Ghostscript will think these are the same font, and will be unable to efficiently create compact output. The presence or absence of the PDF/A switch, however, makes no difference. Acrobat produces the same dialog both ways. This dialog only seems to appear when printing, and seems to be limited to Adobe Acrobat, I can't find any other PDF consumer which objects to the file. I also cannot see anything incorrect about the file, nor the font Acrobat complains about. The file also appears to print correctly from Acrobat. In the absence of anything concrete to go on I'm unable to see a way to proceed with this.
Subset fonts with the same prefix are legal and are intended to allow glyphs to be incrementally be added to the subset, so I'm not sure why this is 'bad practice'.
(In reply to comment #2) > Subset fonts with the same prefix are legal and are intended to allow > glyphs to be incrementally be added to the subset, so I'm not sure why this > is 'bad practice'. You are mistaken, the PDF spec says: "For a font subset, the PostScript name of the font—the value of the font’s BaseFont entry and the font descriptor’s FontName entry—begins with a tag followed by a plus sign (+). The tag consists of exactly six uppercase letters; the choice of letters is arbitrary, but different subsets in the same PDF file must have different tags." So it's not just bad practice, it's downright wrong.
(In reply to comment #2) > Subset fonts with the same prefix are legal and are intended to allow > glyphs to be incrementally be added to the subset, so I'm not sure why this > is 'bad practice'. Not in PDF files, you can't incrementally add to a font in PDF. Also, these are *different* subsets, with (potentially at least) different glyphs at the same encoding position.
Sorry. I shouldn't comment from my (obviously faulty) memory, but should check the spec. Thanks for the correction, Chris.
(In reply to comment #5) > Sorry. I shouldn't comment from my (obviously faulty) memory, but should > check the spec. > > Thanks for the correction, Chris. NP. It happens to be a particular bugbear of mine that a) so many PDF creating apps do it, and b) Acrobat doesn't care (I don't think even the normal pre-flight lists it as an error!).
Assigned to Marcos to contact Adobe regarding the error in the original Description.
(In reply to comment #7) > Assigned to Marcos to contact Adobe regarding the error in the original > Description. Are there any news from Adobe why the Adobe Reader says "Cannot extract the embedded font"?(In reply to comment #7)
For me this problem is resolved with commits 8b6be8be2cdcefae39339682d45d3c009ab909ac and then a5fa1ac21714a2dfdbcd3b9d70bc5cd913764ef3 You need both, applied in that order. I'm baffled as to why Acrobat only complains when printing though.