platform: Win32 postscript creator: pscript5.dll (tested on Windows 2000 and XP) A postscript file is generated from text with several Windows truetype fonts including Palatino Linotype. When the postscript is distilled to pdf without embedding any fonts, Palatino Linotype font gets corrupted while there are no problems with the other fonts. (tested fonts = Arial, Times New Roman, Verdana, Palatino Linotype) gs -q -dSAFER -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -sOutputFile=out.pdf -c ".setpdfwrite << /EmbedAllFonts false >> setdistillerparams" -f in.ps This is the command used to create the corrupt pdf file. The problem is not with the pdf viewers. I checked with several pdf viewers and the result was the same. I also tested the same postscript file with Acrobat Distiller (again without embedding the fonts) and there were no problems with the resulting pdf.
Created attachment 4174 [details] input postscript file This is the postscript file from which Ghostscript creates the corrupt pdf.
The embedded Type 42 (TrueType) Palatino fonts use non-standard glyph names (eg /g18). All the fonts in the original document use a non-standard Encoding, pdfwrite (unlike Acrobat Distiller) does not generally alter the Encoding of fonts and as a result the PDF file contains font descriptors with a non-standard encoding. When the fonts are embedded, this is not an issue, however when the fonts are not embedded the PDF consumer must substitute the missing fonts with fonts available to it. When the glyph names are standard, this is possible, and so the fonts with standard glyph names render correctly. The fonts which do not have standard glyph names (all the Palatino fonts) cannot be substituted in this way as the TrueType fonts being used for a substitute do not have the same glyph names. So the consumer falls back to simply using the character encoding. Because pdfwrite has preserved the original PostScript custom Encoding, this also fails, so the /.notdef glyph is used instead. /.notdef is defined as GID 0 for TrueType fonts, so this is what is used, which is why the text appears as it does. The file is not corrupted, its simply that not embedding the fonts has removed too much information from the resulting PDF file, and the non-standard fonts cannot be successfully substituted. The only way to solve this would be to re-encode the fonts as *some* versions of Acrobat do. This has already been attempted, but we are unable to uncover how Adobe Acrobat Distiller is able to find the correct encoding for non-standard fonts, with custom glyph names, using a non-standard encoding.