When compressing (-dPDFSETTINGS=/screen) the attached file I get multiple warnings regarding embeded fonts which could not be processed. The resulting PDF-file lacks all text information. Expected result: PDF-file with lower filesize Actual result: PDF-file without text The original file was created by Filemaker PRO Version 11. Ghostscript tells me that the "Adobe PDF Library" was used to compose the PDF. It seems that this problem exists for quite some time now: http://bugs.ghostscript.com/show_bug.cgi?id=690310 http://stackoverflow.com/questions/3774995/pdf-how-to-optimize-filesize-convert-to-png-embedded-fonts-problem In my search for a workaround I stumble across the XPDF-library which seems to have corrected this problem in the recent version. I tried pdftops in version 3.02 and 3.03. While 3.02 seems to have the same problem as ghostscript, version 3.02 manages to create a PS out of the PDF. This PS actually can also be processed by ghostscript resulting in the expected output expected directly from ghostscript in the first place. I will post all files/outputs i have used/got for comparison.
Created attachment 8950 [details] Original PDF file created by FileMaker Pro 11 (on Mac)
Created attachment 8951 [details] Actual result when using GS9.04 directly
Created attachment 8952 [details] Command used to convert and Shell Output
Created attachment 8953 [details] PS File created with XPDF 3.02
Created attachment 8954 [details] Command used to convert with XPDF and Shell Output
Created attachment 8955 [details] Resulting PDF when using XPDF 3.02 and Ghostscript 9.06
Created attachment 8956 [details] PS File created with XPDF 3.03 (No errors/warnings reported)
Created attachment 8957 [details] Resulting PDF when using XPDF 3.03 and Ghostscript 9.06
Maybe it is possible to include the solution used in XPDF into Ghostscript.
The basic problem is, as stated in bug #690310, that the *original* file contains a corrupt font. Processing a broken file happens to lead, not too surprisingly to an even more broken file. This is not a problem with the font API, nor is it a 'major' problem. The problem results because we don't simply embed the broken font from the original document, we process it to produce a potentially smaller font. That processing is confused by the error in the original font and so fails. The best approach to this is to fix the original document, perhaps you should raise the faulty font embedding as a bug with Adobe. When I get a chance to revisit the TrueType font embedding code I will consider this file and see if anything further can be done about it. However this is likely to be some considerable time.
OK, sry! I may have set the importance level too high. I understand the underlying problem with the faulty embeded Font. But in the XPDF library they seem to have found a workaround for this. The main problem is, that this faulty file is created in a (sub)sytem which is not in our administration. The company behind it say its not their fault cause the original PDF is viewable in Acrobat. And directly contacting Adobe won't help either. Do you see any chance that this could be corrected at your end? Isn't it possible to NOT process the font in case of brokenness and keep the original?
(In reply to comment #11) > The main problem is, that this faulty file is created in a (sub)sytem which is > not in our administration. The company behind it say its not their fault cause > the original PDF is viewable in Acrobat. And directly contacting Adobe won't > help either. Why not ? The font is demonstrably broken. > Do you see any chance that this could be corrected at your end? Yes, possibly, but it means rewriting the TrueTtype font embedding code, which is on my long-term 'todo' list. > Isn't it possible to NOT process the font in case of brokenness and keep the > original? No, because we *never* preserve TrueType fonts unchanged, changing this is as large a project as rewriting the embedding code.
I notice that the current version of Adobe PDF Library is 'X' and the current version of Adobe FileMaker is 12, perhaps an upgrade might have a bug fix for this problem.
(In reply to comment #12) > (In reply to comment #11) > > Isn't it possible to NOT process the font in case of brokenness and keep the > > original? > > No, because we *never* preserve TrueType fonts unchanged, changing this is as > large a project as rewriting the embedding code. Ok! Thanks for clarification. I'm a software developer myself and I wouldn't do such a big scale change either ;) (In reply to comment #13) > I notice that the current version of Adobe PDF Library is 'X' and the current > version of Adobe FileMaker is 12, perhaps an upgrade might have a bug fix for > this problem. This was my next intention. I just wanted to verify if there is a quick 'n dirty solution to this which I probably could do myself but it doesn't seems so. So, thank you for your time and good bye.
I confirm that this problem existed v.9.06 but it was fixed in v.9.07 and remained fixed ever since. This bug report can be closed.
(In reply to Peter Cherepanov from comment #15) > I confirm that this problem existed v.9.06 but it was fixed in v.9.07 and > remained fixed ever since. This bug report can be closed. No. This bug is intentionally left open as its an area I intend one day to revisit and I want all the relevant bugs easy to find when I do. There are a number of such bugs, all related to TrueType fonts, open and assigned to me for this reason.
I must admit that I totally forgot about this bug. It feels like a ghost from the past. Current situation: We in our company were able to enforce PDF/A as a minimum standard for all external documents and do a validation prior to accepting anything. So the company supporting the faulty implementation was forced to do something about it, but it was a long struggle to get this far (about 2 to 3 years) What still baffles me to this day is the fact that Adobe Reader amongst other tools was able to handle the faulty font without even a flinch.