Created attachment 13172 [details] PDF with all fonts embedded When the file Info4.pdf is converted to EPS (eps2write), Adobe Distiller 10/11/DC is not able to distill the created EPS-File (Info4_0001.eps). Distiller-Messages: %%[ Error: limitcheck; OffendingCommand: awidthshow ]%% Stack: 0 500 0 0 500 /x -mark- -dict- 5 %%[ Flushing: rest of job (to end-of-file) will be ignored ]%% %%[ Warning: PostScript error. No PDF file produced. ] %% GS9.19 (or GS9.20) was called like: gs -sDEVICE=eps2write -I%gs_config%;%gs_lib%;%gs_fonts% -sOutputFile=Info4_%%04d.eps Info4.pdf I know, I reported a similar problem 2015-09-10, Bug 696189. But, while the pdf from 2015 had no embedded fonts, the actual pdf (Info4.pdf) has all fonts embedded. The problem from 2015 could be solved, using external Type1 Fonts instead of TrueType Fonts when generating EPS files. Hence Info4.pdf has all fonts embedded, this workaround does not work. I know, GhostScript can deal with EPS file created from Info4.pdf, but we like to print PostScript (generated from GhostScript) on different printing systems (PRISMA, FreeFlow ...), which are using different versions of Adobe Distiller software. Even if Adobe will solve the problem in distiller, we can not get a solution on all printers shortly. Some printers will in fact never be changed. So, can you see a possibility to change the EPS output, so it works for Adobe Distiller ? When not, can you advice for a workaround, which can be done by ourself ? for example: - Distiller options - Redefinition of awidthshow - other GS options Is there a possibility, to recognize with GhostScript functions (analyzing pdf) that this problem will raise later ? Thanks. Reiner
Created attachment 13173 [details] EPS which cannot be distilled by Adobe Distiller
*** This bug has been marked as a duplicate of bug 697245 ***
Well, according to the (Adobe) PostScript Language Reference Manual, limitcheck is not a possible error from awidthshow. In fact, the problem appears to be due to the font being used, if I remove the ',' from the EPS file then it works correctly. I note that the original PDF file uses only the font ScalaOffc, but includes two subsets of that font, which suggest some problem with the original to me. If you can tell me why Acrobat throws an error on what appears to be a valid font, which other PostScript interpreters are happy with, then yes, I can fix it. But in the absence of that information I don't see what I can do. My guess is its an architectural limitation of the type 42 font interpreter in Distiller, but that is merely a guess. Of course, starting with a PDF file, converting it to EPS and then running it back through Distiller to make another PDF file doesn't make any sense. I am not in a position to advise you in any way on Adobe Distiller options, other than to point out that if you have a PDF file already, converting it into EPS and then back to PDF seems a rather pointless step. If you don;t do that then you will avoid the problem. Redefining awidthshow won't help you, because the problem appears to be the font. Your only option with Ghostscript is to use -dNoOutputFonts which will convert the text into vectors and omit the fonts entirely. Since I have no clue what Acrobat is complaining about, I cannot see any way that Ghostscript can tell you the problem is going to arise with Distiller. I've tried the file on Ghostscript, another software PostScript interpreter and an HP PostScript printer, and all are able to render the file without problems. This means to me that this problem is highly specific to a limitation of the Adobe implementation (possibly even specific to Distiller), most likely is specific to a font, and possibly a peculiar font (since the PDF creator embedded two subsets. Given that situation, if you can find out (perhaps from Adobe, since you seem to be significant users of their products) what exactly their interpreter doesn't like about this font, then I'll be willing to attempt to fix it. I'm not prepared to fumble round in the dark on this one. Perhaps you could open a bu report with Adobe and ask them for help.
Hi Ken, after a long time, we got finally a answer from Adobe: "The font has 350 glyphs, and the 'hhea' table says there are 16 long form (advance width and left-side bearing) metric pairs. So the 'hmtx' table should be 16 * 4 + (350 ' 16) * 2 bytes long. It isn't, it's only 64 bytes long. It is missing all of the short-form (left-side bearing only) metric data. The test that is failing in the code is assuming the 'hmtx' table is large enough to contain all the data, but then goes to try to access it and goes off the end of the font. So, ours initial investigation shows that the font has a problem. We are still working on this problem and will see whether we can find a workaround, which can work even with this problematic font. We will keep you updated." Do You see a possibility (based on Adobe info), to modify the fonts in (e)ps2write output, so it can be handled by Adobe Distiller ? Even if Adobe will change it's software, it will last a long time until all Adobe rips are updatet (Windows Distiller, Xerox FreeFlow/DocuSP, Canon Prisma...),so I would prefer a solution well done by you. (That would be much more faster and would work everywhere...) Many thanks. Reiner
(In reply to Reiner Saalfrank from comment #4) > after a long time, we got finally a answer from Adobe: Firstly, congratulations on extracting useful information! > Do You see a possibility (based on Adobe info), to modify the fonts in > (e)ps2write output, so it can be handled by Adobe Distiller ? Its possible, yes. Unfortunately the pdfwrite code family's routines for rewriting TrueType fonts are elderly and not (in my opinion) well written in the first place. This code relies on modifying some TT subtables, creating others ones from scratch and simply reusing some subtables unmodified. This unholy mixture leads to the sorts of problem you see here. I have had a long term task on my TODO list from some time to completely rewrite this code, there are a number of problems with it I'd like to address. However I have to admit that a complete rewrite is not likely to happen any time soon. I will take a quick look at the code and see if there's a 'quick' solution (aka another nasty hack) we can do.
Commit 6cae884b66944318c34e17992c628a246dda18aa fixes this particular problem for me.