PDFCreator 2.0 & Searchable PDFs

Is there a reason PDFCreator 2.0 doesn’t create searchable PDFS like .7 and earlier did?  Based on the file sizes, the new version is creating a PDF containing page images instead of a PDF containing lines/text/etc.

Is there a setting hidden somewhere to change this behavior?  It seriously increases the file size.  (42KB from 1.7.3 vs. 120KB from 2.0.0)

Hi,


I’d say this is done by the printing application rather than PDFCreator, but if you can provide an example where printing to 2.0.0 results in images and printing from version 1.7.3 results in searchable text (from the same version of the same printing application) we will have a look at why this is happening and try to fix it. Usually it is printing from browsers which causes this behavior, which can change with the version of the browser.

best regards,


The app we’re printing from is a long-standing custom application that uses the VB6 Printer object.  We’re printing forms and data for orders and invoices.  In the code, we draw lines, arcs, and boxes and place text and images on the page.

In 1.2.0 and 1.7.3, the PDFs were searchable, and we could select and copy text from the resulting PDF.  In 2.0.0, we can no longer select the text, and the file size (for one sample) went from 42KB to 120KB, which would indicate that the PDF is a page-image, since that’s similar to the size of the PDF created when a physical print the page is run through a scanner.  (The scan is slightly larger, but that’s likely due to the fact that the page doesn’t all read as perfect black/white.)

Thanks for the feedback.

The fact you are printing from a custom application will most likely make the troubleshooting a bit more difficult, but at least you can rule out that any changes were made to the code of the priting application. Could you send a copy of the .ps file from any of your applications print jobs to support@pdfforge.org?
Or you could try sending the .ps file through ghostscript 9.10 (which is used for PDFCreator 1.7.3) and 9.15 (which is used for PDFCreator 2.0) and see if this causes the change (but if you send us the .ps file we will do this).

best regards,

What’s the best way to get the .ps file for the print job?  We don’t have any stage where we end up with one, so I’m not sure how to get get one.  Is it an intermediate file that I can capture, or do I need to change the settings on PDFCreator to get it?

Hi,


sorry I should have mentioned this: The .ps file is the temporary file which gets created for each print job, it gets placed in Users\Username\AppData\Local\Temp\PDFCreator\Spool once you send a print job to the PDFCreator and before you press save. If it is to large to send by mail please upload it somewhere.

best regards,


Well, I’m not sure what happened, but I’m now getting searchable PDFs from 2.0.0.  Unfortunately, the copy/paste results look exactly like what we were seeing before which got us looking at upgrading.

All output files can be found here: https://www.dropbox.com/sh/wnikgvs8uv81rim/AADcmN71xeEN7MvBgKt3gJLOa?dl=0

When we select text from the PDFs, copy it, and paste it into a text editor, we get gibberish.  We believe this is what is causing problems with a 3rd party app (SmartSearch by Square9) when it merges multiple PDFs.

For example, when you copy the ‘Sold To’ address from the PDFs in the link above, the pasted text reads:
WA{EXT}{EOT}ART C    RP{VT}B
Y V540253
ATT{NAK}{SYN} I{NAK}V    ICI{NAK}G C{ETX}ER

EDI BI{ETX}{ETX}ED ACC    U{NAK}T
.{GS} AR .
U{NAK}ITED STATES

(Note: The strings inside the curly brackets represent special characters, rather than standard ASCII text.  They are visible in Notepad++, but they show up as extended ASCII characters in Notepad, and are not visible in the text editor for these forums.  The values written by our custom application producing the print jobs in question outputs the strings visible in the PDF.)