Log in to create and rate content, and to follow, bookmark, and share content with other members. Not a member? Join Now!

AnsweredAssumed Answered

Error 29062 "timeout processing the PDF document"

Question asked by Paul LaFollette on Nov 22, 2019
Latest reply on Dec 5, 2019 by Jeff Geller

Like • Show 0 Likes0
Comment • 6

I'm seeing instances of Error Code 29062 "timeout processing the PDF document" with certain PDF files (usually PDF files).

Typically, user has obtained or generated a PDF file, then uploaded the PDF file to Mobile Print. When releasing the document the Uniprint fails to print with no error message, however a few moments (or a few minutes) later the document shows in the queued jobs flagged as "Free Print". In Pharos Administrator Alerts the error is logged stating "timeout processing the PDF document". Despite the job now being shown as "Free Print", Uniprint is never able to print the document.

Trying to "tweak" the file (using Acrobat or other tools) doesn't help. Re-printing the file to a different PDF creator (like "Microsoft Print to PDF") successfully creates a new PDF file that will print through Mobile Print.

Who else is seeing this? Any suggestions?

I've already reviewed the driver settings for Mobile Print and even created new render print objects in the hope it might help (it didn't).

Thanks,

- Paul L.

Jeff Geller Nov 22, 2019 3:51 PM

Correct Answer

Hi Paul,

Looks like you have a PDF that is not quite as simple as some can be,. PDF documents can be generated by many different applications and no two do the same thing out of the box, meaning some "flatten" those complex files when they are created and some don't unless specifically configured to do so.

The other part to the "Render" equation is the print driver used. I have seen some process those pesky PDF documents better/faster than others and some not so much, different drivers can produce different results. Often it is not a setting in the driver that you can tweak to make it work better, often it is switching from a PCL driver to a PS driver (or the other way around) for the Rendering of the file through a PDL that creates a print ready file for the device to chew on.

I have also seen small-ish (25MB files) with 200 or 300+ pages from a scanner device, meaning someone scanned a book to PDF and when the PDL gets it it takes minutes and days for it to chew on that file thus creating a large spool file in the Gigabytes. Most often those files take fuhever when printing through normal Windows methods, meaning direct TCP/IP ports to device. The Print Spooler processing it can be seen to take up to 15-20 minutes to simply complete the process so the file becomes something the device will print. It is those "scanned pages" that creates image files per page that causes the PDL (Print driver) to hunker down and get to work processing the image data, takes a while for some drivers and other not as much.

When you print to the print queue first, the file gets rendered at that time so when it gets "through the server" to the Secure Release Port Monitor it is already ready to go to the printer. No additional processing is needed other than the device has to chew on the file to put ink to paper. When doing it this way, the user is often going to have a few minutes as they finish something, go to device, login, see job and release it.

-Jeff

See the reply in context

No one else had this question

Outcomes

6 Replies

Jeff Geller Nov 22, 2019 3:51 PM
Unmark Correct
Correct Answer
Hi Paul,

Looks like you have a PDF that is not quite as simple as some can be,. PDF documents can be generated by many different applications and no two do the same thing out of the box, meaning some "flatten" those complex files when they are created and some don't unless specifically configured to do so.

The other part to the "Render" equation is the print driver used. I have seen some process those pesky PDF documents better/faster than others and some not so much, different drivers can produce different results. Often it is not a setting in the driver that you can tweak to make it work better, often it is switching from a PCL driver to a PS driver (or the other way around) for the Rendering of the file through a PDL that creates a print ready file for the device to chew on.

I have also seen small-ish (25MB files) with 200 or 300+ pages from a scanner device, meaning someone scanned a book to PDF and when the PDL gets it it takes minutes and days for it to chew on that file thus creating a large spool file in the Gigabytes. Most often those files take fuhever when printing through normal Windows methods, meaning direct TCP/IP ports to device. The Print Spooler processing it can be seen to take up to 15-20 minutes to simply complete the process so the file becomes something the device will print. It is those "scanned pages" that creates image files per page that causes the PDL (Print driver) to hunker down and get to work processing the image data, takes a while for some drivers and other not as much.

When you print to the print queue first, the file gets rendered at that time so when it gets "through the server" to the Secure Release Port Monitor it is already ready to go to the printer. No additional processing is needed other than the device has to chew on the file to put ink to paper. When doing it this way, the user is often going to have a few minutes as they finish something, go to device, login, see job and release it.

-Jeff
1 person found this helpful
Like • Show 2 Likes2
Actions
- Paul LaFollette @ Jeff Geller on Nov 27, 2019 10:22 AM
  Mark Correct
  Correct Answer
  Jeff Geller
  Thank you.
  
  Quoting you: "Often it is not a setting in the driver that you can tweak to make it work better, often it is switching from a PCL driver to a PS driver (or the other way around) for the Rendering of the file through a PDL that creates a print ready file for the device to chew on."
  
  Switching the renderer from a PCL driver to a Postscript driver appears to have fixed the issue for me (and of course, assigning that driver to the printer models in MobilePrint's Driver Mapping). Had to be a fairly new Postscript driver as older driver versions may not handle the characteristics present in many of the newer PDF files (because of how newer programs generate the PDF files).
  
  Thanks again.
  - Paul L.
  1 person found this helpful
  Like • Show 1 Like1
  Actions
  - Scott Olswold @ Paul LaFollette on Nov 27, 2019 1:57 PM
    Mark Correct
    Correct Answer
    Paul,
    
    The choice between PCL and PostScript drivers for MobilePrint output is highly dependent on the manufacturer and version. But version of what?!?
    
    PostScript. Adobe's PostScript language has been released in 3 different versions in its lifetime: PostScript Level 1 (1984), PostScript Level 2 (1991), and PostScript 3 (1998). There has not been much development to the PostScript language itself since 1998.
    PCL. There are 6 major revisions to Hewlett-Packard's PCL language, and one version (PCL 5) had two additional releases to support various features. PCL 1 was released in the late 1970s and supported only basic ASCII output. PCL 2 was released in 1982, and improved on PCL 1 by adding multi-user processing capability. PCL 3 came into being in 1984 and supported crude graphics/bitmap capability; introduced with the original HP LaserJet printer. PCL 4 arrived in 1985, and supported better graphics output and macros; introduced with the HP LaserJet II printer family. PCL 5 hit the scene in 1986, and was largely a response to the success of PostScript in the emerging Desktop Publishing market, spurred mostly by the Apple Macintosh, Aldus PageMaker, and the Apple LaserWriter (which offered built in PostScript support); it supported better graphics, font scaling, improved macro support, and HP-GL/2 (vector) graphics support and was introduced with the HP LaserJet III. PCL 5 enjoyed two minor releases: PCL 5e ("enhanced") for bidirectional support and better support for Microsoft Windows; PCL 5c ("color") supported color output. The big splash came with PCL 6 (or, PCL-XL) in 1995. It was a radical update and was not backwards-compatible, offering newer commands and other changes that effectively made it a different language.
    PDF. Adobe's Portable Document Format (PDF) specification has slowly grown to replace PostScript, offering support for both layers and transparency in PDF 1.4 in 2001, while PostScript 3 still relied on crafty matting and rasterizing to handle those new attributes. Adobe made a strategic shift to PDF as both a document format and document output language. The current version, PDF 2.0, was released in 2017. It is fair to say that the capabilities of the PDF language since version 1.4 has made output to devices exceedingly more difficult. In 2006, Adobe released the PDF Print Engine, which allowed for a complete PDF-based workflow. Adoption in the business market has been non-existent, but in prepress and high-end graphics, it has made life (and output) better by one hundred-fold.
    
    On the flip side, manufacturers update their printer drivers (based around either the PCL or PostScript languages, or around proprietary formats like EPSON's ESC P/2) to accommodate new printer features and capabilities. The underlying language for PCL and PostScript drivers remains unchanged from either PCL 6 (remember: 1995) or PostScript 3 (1998). The old, and static, nature of the underlying printer language makes modern PDF printing...well, hard. Search any manufacturer and driver version for "problem printing PDF" and you'll see.
    
    When a PDF file is received by MobilePrint, we don't do that much to it. The pages are rasterized for thumbnails (the "Preview" function in Print Center) and the file is encrypted for storage, but that is about it. When it is time to print the job, the PDF goes to the printer driver as-is with the requisite job attributes (single/double-sided, color/mono, n-up). From there, it is up to the Windows Print Spooler to manage the PDF through the printer driver and then on its way to the printer. And while we know that you cannot control what type of PDF is sent to MobilePrint, these PDF capabilities will cause extra headache for the Windows Print Spooler and the printer driver assigned to the output device:
    
    Transparent objects. Heavy CPU and moderate RAM to perform the necessary rasterization within the printer driver.
    Layers. Heavy CPU and heavy RAM to support the necessary rasterization within the printer driver.
    DeviceN color space. DeviceN is used for things like spot colors and Pantone-defined objects. Moderate RAM usage to convert to RGB.
    Non-stitched raster objects. If the PDF contains larger, high-resolution raster objects (like a TIFF, JPEG, PNG) that haven't been broken down into smaller elements (this typically happens during optimization of the PDF in Adobe Acrobat or its "printer" operation), the image has to be handled as one blob in memory. Remember that a 4"x6" photo at 300 pixels per inch is 6.17MB, so that means the spooler will need to temporarily allocate at least that much plus other page elements when committing the PDF to PCL or PostScript. If that same object is split into smaller chunks, memory use is more efficient.
    Whacky fonts. If the PDF contains non-standard (based on the printer driver's support) fonts, then the Spooler will need to convert those, typically into raster format, first. When a PDF document contains printer-resident fonts, then the driver only has to send down the text with a "use this font at this point size" command. Heavy memory and moderate CPU.
    High compression. That 4"x6" photo that takes 6.17MB in memory can end up in a PDF file as a 64KB block of data. When printing, that data has to first be decompressed before it can be added to the print file sent to the printer. Decompression is an expensive CPU operation.
    Junky PDF generators. Not all "convert to PDF" functions are equal. Many of the freebies that can be downloaded and installed may follow an earlier, non-optimized PDF specification (the end result: page after page of high resolution, non-optimized image data), or are just bad. Heavy CPU and memory.
    
    Does PCL or PostScript manage this better? It depends on the manufacturer, and whether they are using licensed PCL (from HP) or PostScript (from Adobe) on the printer; if the printer is using an emulated language interpreter, then the driver is most likely using some bad fabrication of language derived from that interpreter, and problems can happen. It will require testing and validation on your part to determine what is best for a tested range of PDF files. A lot of problems in output or resource utilization can be fixed by what is commonly called "refrying a PDF." This means that you open the PDF in Adobe Acrobat (a non "Reader" edition) or Foxit's PDF suite and "export to PDF" or print to that application's PDF queue. Datalogics, the company that provides the library we use to convert inbound docs to PDF for MobilePrint, has a free PDF Checker utility (https://www.datalogics.com/products/pdftools/pdf-checker/) that can quickly identify where the potential problem might be coming from.
    
    I hope this helps,
    Scott
    5 people found this helpful
    Like • Show 1 Like1
    Actions
    - Paul LaFollette @ Scott Olswold on Nov 27, 2019 4:22 PM
      Mark Correct
      Correct Answer
      Thanks, Scott! Great info.
      
      - Paul L.
      1 person found this helpful
      Like • Show 1 Like1
      Actions
  - Jeff Geller @ Paul LaFollette on Dec 5, 2019 11:05 AM
    Mark Correct
    Correct Answer
    Hi Paul,
    
    That's what makes printing so much fun these days and the print world go round. The PDF creator/tool changes and adds new flair to the document and the driver needs to be changed as well to work better to process said new flair, then the PDF creator/tool changes again invalidating your most recent happiness with the updated driver and now we have to hunt a better one down again. Wash, rinse repeat.
    
    -Jeff
    Like • Show 0 Likes0
    Actions
Jason Spring Dec 5, 2019 11:13 AM
Mark Correct
Correct Answer
Hi Paul,

We recently had a long-term problem with Mobile Print jobs failing with this exact same error, 29062 "timeout processing the PDF document", except it was not specific to documents that originated as PDFs, but rather any Mobile Print job, as they all get converted to PDF for printing. It could be anything, a PDF, a word doc, even a simple .txt file with a single line of text. It was also only Mobile Print jobs. Any jobs sent from lab desktops via pop-up pkgs worked fine, including PDFs.

Students would upload their doc to Print Center, swipe their ID card at the release station to pay for and release the job to the printer, but the job never gets printed. As you describe, after a few minutes the job would show back up as [Free Print], but even then, attempting to print or have an admin push the job would still result in nothing being printed, and the job would disappear. Students were getting charged for the print but never receiving it. It was causing quite a lot of problems for Print Desk/Service Desk, as you can imagine.

The problem was varied, in that under normal circumstances, there would be a handful of these failures occurring every hour, often in spurts, but at times the problem would build up to more and more failures until it reached 100% failure rate for all Mobile Print jobs. A restart of the MP Worker Service/Print Spooler on the MP server (two server setup, a Principle Uniprint server and an MP server hosting Print Center/MobilePrint) would be required to recover from the 100% fail state, but the cycle would generally repeat and build up to the 100% failure state again at some point. In fact, the workaround we had to implement while trying to solve the issue was to schedule a restart of the print spooler on the MP server at the top of every hour.

We lived with this for many months, working with Pharos Support all along the way, as nothing we found and nothing we tried ever seemed to resolve the issue. It was improved slightly with tweaks to renderer counts and the like, but it never really went away, until finally, at the suggestion of Support and their experience with another customer in a similar predicament, we simply updated the drivers we were using on the MP server renderer queues (HP UPD 6.6 to 6.8). Voila, no more (excessive) 29062 timeout failures for Mobile Print jobs.

My rough guess at this point is that it was down to some fluke issue between the PDFs that the MP document converter was creating (?) and the HP UPD version we were using having trouble with those PDFs. We were (and still are) using the same HP UPD 6.6 on the Principle server and it never had issues with native PDFs, so it seems the problem was at least in part caused by the PDFs created by Mobile Print, but likewise, the newer HP UPD 6.8 is able to handle the PDFs created by Mobile Print just fine, so clearly there was an issue with UPD 6.6 as well.

It looks like changing drivers was the solution for you guys as well. Glad you got it sorted!

TL;DR - For anyone seeing this issue or something simliar, don't overlook trying a different driver, as at least in our case, that's where the 29062 timeout processing PDF issue was stemming from.

-Jason
Like • Show 0 Likes0
Actions

Incoming Links

Re: a new 29062 error (new to me )

Error 29062 "timeout processing the PDF document"

Outcomes

Related Content

Recommended Content

Incoming Links