ghostscript：lost pdf original embedded font

Question

When I use command gs -sDEVICE=pdfwrite -dNOPAUSE -dBATCH -dNOOUTERSAVE -dSAFER -dPDFSETTINGS=/prepress -dCompressFonts=true -dSubsetFonts=false -dEmbedAllFonts=true -sColorConversionStrategy=RGB -dCompatibilityLevel=1.6 -sOutputFile=output.pdf new27.pdf to convert my pdf file, then I get new file.

I find an error in this new pdf file when I open it in Adobe Acrobat Reader: new pdf screenshot

this is original pdf's fonts: original

this is new pdf's fonts after converted: new

Whether there is a parameter controlling ghostscript does not change the embedded font?

Answer 1

Well, the problem is that the type 1 font data is not being embedded, and because these are subset names (and using custom encodings as a result) there is no way for a PDF consumer to create a working substitute font.

The FontDescriptors are present, but the actual font data is not. I have no idea why, I've never seen a problem like this before, you should report a bug to https://bugs.ghostscript.com.

It would probably help if you could find (or create) a much simpler example, the original file has 4 pages and uses 18 type 1 fonts, none of which appear to be embedded in the output. A single short line of text using one font would be ideal if you can create that.

Update

One of my colleagues looked at the file for me. The problem is in the PDF file, specifically the fonts. Each font contains a /.notdef glyph (which is required) and each one begins with an undefined op code (0x00). This means the font is genuinely broken.

So why doesn't this cause a problem for Acrobat (or, indeed, Ghostscript when rendering) ?

Because ordinarily the /.notdef glyph isn't used, it's only used when you try to draw a glyph which isn't present in the font (and is therefore a required entry in the font, it's the only glyph which must be present).

But when creating a PDF file the Ghostscript PDF device converts the type 1 font to a more compact form, the Type1C or CFF font. That means parsing the glyph descriptions, and one of the descriptions that it must use is the /.notdef, because that's required in all fonts.

When Ghostscript tries to parse the /.notdef glyph it fails, so it abandons embedding the font. It still emits the FontDescriptor in an attempt to produce a working file; if the font was not subset a usable replacement might be found. In this case, because the font is subset and uses a Custom Encoding that isn't possible.

There are other aspects of the font which are less than ideal, for instance the Font BoundingBox is defined as /FontBBox [0 0 0 0] which is clearly nonsense. The font name is, basically, garbage and what appears like an attempt at a subset prefix is incorrect, it should be XXXXXX+, ie 6 characters then a '+', not 3.

By the way, the pictures in your original post have font names which don't match (not even a little bit) the names of the fonts in the PDF file you attached. That means I can't be absolutely sure that it's the same problem, but I would suspect it is.

If you open the file in Adobe Acrobat, export to PostScript, and then attempt to create a PDF file from that PostScript using Adobe Acrobat Distiller it throws an error:

%%[ Error: invalidfont; OffendingCommand: definefont; ErrorInfo: .notdef --nostringval-- ]%%

So an Adobe application also throws an error when processing the font.

I don't know where you sourced the font(s) you are using, but you should replace them with better ones, these are broken.