Results 1 to 4 of 4

Thread: cups-pdf functinality broken in 42.3

  1. #1

    Default 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.

  2. #2

    Default Re: cups-pdf functinality broken in 42.3

    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.

  3. #3
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    2,555

    Lightbulb Re: cups-pdf functinality broken in 42.3

    Quote Originally Posted by tgraham_afcorp_com View Post
    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.
    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 …

  4. #4

    Default Re: cups-pdf functinality broken in 42.3

    Quote Originally Posted by dcurtisfra View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •