We recently are seeing multiple users experiencing 29100 ghostscript errors when users are trying to print or send to email using pdfcreator 2.5.2 from a already created pdf. We suspect that this could be due to the pdf's having restrictions on the file.
The pdfcreator logs look to indicate it is failing when the fonts are being queried. However, I've seen mentioned in the forums that this ghostscript error is usually for some type of restrictions placed on the file that is being converted. I'll attach the log below
2018-01-29 14:01:26.7322 [Error] pdfforge.PDFCreator.Conversion.Ghostscript.Conversion.GhostscriptConverter.DoConversion: Ghostscript execution failed: Scanning C:\Windows\Fonts for
fonts… 674 files, 482 scanned, 457 new fonts.
Querying operating system for font files…
Can’t find (or can’t open) font file %rom%Resource/Font/ArialNarrow-Bold.
Can’t find (or can’t open) font file ArialNarrow-Bold.
if a PDF with security restrictions is printed from Adobe Reader, Ghostscript will not allow to create a new PDF from it directly. Normally, this would show up in the log directly (e.g. “redistilling encrypted PDF isn’t permitted”), so I am not sure if this is actually the issue here and if there might be other additional issues. Does converting the same document to an image format with work?
Yes, It does work when you go into the advanced print settings and use “print to image”. In the log file it shows the fonts are not available. Is that where the Ghostscript error is generated?
yes it seems to be an issue with reading some of the required font files, not sure what could cause this though, potential sources might be corrupted files or bad permissions, but I can only guess.
Hi Robin,
I work with the b3235 and we have been looking into this issue extensively.
Here is the process being used when the error happens:
We use an OEM Web product that generates a PDF from a form that a user fills out.
That PDF then opens in Internet Explorer using the Adobe Reader Plug-in. The user then uses the option to PRINT.
When the user chooses PRINT, they select PDFCreator as the printer and click on PRINT. This is when the 29100 - Internal GhostScript Error is encountered.
What we know:
When the PDF is generated by the webpage and opened in the reader plugin in IE, the Arial Narrow-Bold font is substituted with Adobe Sans MM.
As PDFCreator attempts to generate a PDF from the OEM generated PDF, it looks for the font in C:\Program Files (x86)\Adobe\ReaderDC\Resource\Font, but cannot locate the font. (See log files in this post)
In reading on GhostScript, we have found information that indicates GhostScript cannot handle True Type fonts, which is what the Arial Narrow-Bold font is. But if the font was substituted, is it failing because it cannot locate the Sans font?
We are looking for your feedback on what you believe is the actual reason for the error encountered, and any possible solution. Has this been addressed in a release newer than 2.5.2?
Ghostscript can generally handle True Type fonts and there is no issue when printing a text in Arial Narrow-Bold from Word to PDFCreator on my machine. Is the Arial Narrow-Bold Font present on your system / embedded into the PDF displayed by the IE plugin?
A possible solution/ work around might be substituting Arial Narrow with e.g. Helvetica in the device settings section of the PDFCreator virtual printer’s properties.
We haven’t addressed this in any newer PDFCreator version, but we now use Ghostscript 9.22 instead of 9.19, which might have an impact on the issue.
Additional information on what is causing our 29100 Internal Ghostscript error. I'm seeing a correlation with the error and printing a form to PDFCreator. I'm still digging up more info about what we use in our forms.
The key thing to test is to open the original pdf into a alternative pdf viewer that is not using the Adobe Reader plugin such as Chrome, Firefox or Edge.
In our case it would load the pdf with the following info:
Please wait... If this message is not eventually replaced by the proper contents of the document, your PDF viewer may not be able to display this type of document. You can upgrade to the latest version of Adobe Reader for Windows®, Mac, or Linux® by visiting http://www.adobe.com/go/reader_download. For more assistance with Adobe Reader visit http://www.adobe.com/go/acrreader.
Excerpt in bold below from the second link that explains why ghostscript would generate an error:
"While Acrobat can make a form using form fields, these Acrobat-made form fields are fixed on the page in location and dimension, and the average user can’t modify the layout of the page to accommodate more content. Acrobat can’t make an XFA form, but it can read, display and  XFA forms. In order to make XFA forms, you need to use the Adobe LiveCycle Forms Designer or make it through automation using AEM Forms. LiveCycle Designer was previously included as a component of LiveCycle and in other desktop software bundles, but it is now only available to LiveCycle and AEM Forms customers. Why, you ask? XFA is used heavily by Insurance, Financial Services, Health Care and Government customers who use the business process, security, digital signature, document automation, system integration, and other capabilities of LiveCycle or AEM Forms. In addition, while XFA is included in the PDF specification, few other companies have invested resources in developing solutions around XFA PDF. This includes reading and viewing and interacting with an XFA PDF, so the only way to read, view and interact with an XFA PDF is to use Acrobat or Reader on a desktop computer. This is just fine when the intent is to enable workers in an Enterprise to engage with Enterprise business process using complex forms, but for the general user, it’s overkill."
thanks for the interesting update, this makes sense and will very likely be the cause of the issue.
Not sure why this creates an error while substituting/searching for fonts though.
Does it give the same issue, if you drag&drop a PDF onto a PDFCreator window?
This will directly use the PDF file as input without virtually printing it to the PDFCreator printer, so it won't get converted to Postscript as intermediate step.
I am not sure if XFA is really "included" in the PDF specification, at least according to Wikipedia it was only referenced but not included: https://en.wikipedia.org/wiki/XFA, which would explain why so many products don't support it.
