cups-pdf functinality broken in 42.3

All,

I set up a server in 2006 (openSuse 12.2) that hosts a remote PDF printer that utilizes
a script called pdf2email. This system would accept a print job from our primary UNIX system,
convert the file into a pdf and then email it to the person that submitted the job. Good news is
it has operated flawlessly for the last 12 years. The bad news is I have tried to recreate
this system using Leap 42.3 and am having a critical issue. I can make it “work” but the output
file has issues. Something has changed in either Ghostscript or the backend that is creating the
problem.

Problem: A recipient is attmepting to load the pdf into Monarch, a desktop report mining tool.
That ability is now lost. It will not load.

Observations: Two things. First if you open the files in Okular and check the properties you will
see the backend used on the old server was using texttops/CUPS 1.5.3. This was deprecated sometime in 2013
from what I gather. The backend replacement in Leap 42.3 simply pipes the output into another program called texttopdf.
texttopdf 1.8.2 is listed in the pdf created using Leap 42.3. Ghostscript verion changes from 9.05 to 9.15 repectively.

Second, If I open a pdf in Okular created under opensuse 12.2 and highlight a section of text when I release the mouse button
I will see an option “Search for ‘whatever text I highlighted’”.
If I try the same procedure with a pdf created under Leap 42.3 I receive:
“Search for ‘random series of glyphs’”
I bleieve that the reason Monarch cannot import the file is the same reason Okular cannot generate its search string.

Both PDF’s ‘look’ fine cosmetically.

Any assistance or please point me to a place I might pose this inquiry again.
Thanks.

It appears that the issue is that the ‘new’ cups-pdf has regressed in that it
does not perform ocr. Thus the output file is not searchable. As the document
is merely an image now, it becomes unimportable into the recipients system.

Why oh why are we still losing features? I’ll see if I can bodge something together
to fix it.

Taking a look at the “pdf2email” Python script, it calls Ghostscript with a sack full of options to convert the received Postscript print job to PDF.

Now for the bad news: a couple of years ago, CUPS changed (possibly on your UNIX® systems as well) from pushing Postscript to the printer to, pushing PDF to the printer …

Therefore, possibly, Ghostscript is attempting to convert PDF to PDF, with some incompatible options …

Thanks. I gave up and wrote my own backend.