• Best Wishes to all for a Wonderful, Joyous & Beautiful Holiday Season, and a Joyful New Year!

Slow printing Linux/PostScript Konica-Minolta

mbarchein

New member
Hello, I'm new in this forum and I am having a problem. I'm looking for your expert advice. Please, if this is not the appropiate place to ask, point me to some other forum.

I am a sysadmin experienced in opensource (mostly Linux) solutions. One of our customers is running a printing shop oriented to students. The students send via email some PDF files (A4 paper size) with custom options (n-up, color/bw, page range, etc) and the printing pipeline I've made for my customer automatically does the following:

1) Get the original file
2) Convert it to PDF if job is MS Word / Powerpoint (ghostscript / online conversion service)
3) Process it to generate a new PDF file with the desired output (page ranges, n-up, etc.) (pdfjam)
4) Convert it to PostScript (acroread)
5) Send PostScript to printer (CUPS)

The main problem I'm facing here is that printing is very slow for some types of jobs, mainly with those with lots of raster images (imagine, for example, a job made only of scanned pages)

My customer is using these printers:

- Konica-Minolta Bizhub PRO 1050
- Konica-Minolta Bizhub PRO 920
- Konica-Minolta Bizhub C353
- Konica-Minolta Bizhub C360

All the tools I'm using are Linux based:

- The printers are controlled by CUPS, 1.5.x using generic PCL6 or PostScript drivers (no native drivers for those models)
- Final PostScript files are being generated by "acroread" 9.5.x (Adobe's Official Acroread for Linux). I have tried to use ghostscript but the processing time is too big (20x more) and output files are huge in some cases (several GB for an input PDF file of 20MB)

What I'm observing is very slow feeding of final PostScript file to printer. It seems that printers have a very slow RIP (I think that's the term) that is causing the slowness. Network problems are discarded.

I have been reading about using an external RIP to speedup the process, but I havent found any free solution for Linux, and I don't know if that one is the real problem or not. I have also tried to convert all the pages of the document to raster images. assemble them to postscript again and send the job to the printer, but then the problem gets worse (slower processing times).

Please, could you give me some advice?. I'm not familiar with many printing terms, so please treat me like a newbie.

Thanks.
 
With raster images you are going to be specifying a resolution to print these to. The higher the resolution the larger the file. I would check to see what resolution you are saving your postscript files to. I would even test saving them to 72dpi to see if the process is dramatically faster. From there you will know if resolution is the problem.
 
I don't know, seems to me that the multi-step process you're using, Word-to-PDF-to-PDFjam-to-PS-PS or PCL raster is way too complicated. The more times you convert a file the more opportunities for stuff to go wrong. No wonder the rip chokes on it! I guessing you don't have Distiller which would be your best bet. I get that you're comfortable with Cups printing but why bother, why not just use Windows or OSX printing?
 
Hello again, I found a workaround. Just changed printer driver to "Generic PCL Laser Printer" and it started working really fast. It seems this driver does RIP in software in the CUPS side (high CPU load makes me think so) and the jobs get printed on the fly.

With the "Generic Postscript" or "Generic PCL 6/PCL XL" drivers, jobs need to be completely transfered to the printer before the first printed paged comes out. The "Generic PCL Laser Printer" makes the printer start printing on receiving the first page.

Also, the Word->PDF conversion doesn't give any problems, it's reasonabily fast and only the 5% of the jobs, The other 95% are PDF documents. If I try to print a PDF document mostly made of raster images the problem I described in the first post was the same. Converting to PS using Adobe "acroread" was necessary to reduce job processing time in the CUPS spool, because it internally converts PDF jobs to PS before sending them to the printer and this conversion wasn't better in terms of processing time int the printer side when using internal CUPS (ghostscript), it usually produced longer waiting times.

The other tihings I tried before this solution were:

A) Generating PS files (using ghostscript) with low resolution (150dpi). Almost the same slow results.
B) Generating a bunch of TIFF files (or a single TIFF with all pages) in different resolutions (600, 300, 150dpi) and sending them to the raw port of the printer, bypassing CUPS. Also, slow printing with higher resolutions and mid-to-slow and bad quality with lower ones. Oh, and I could't select duplex or color mode in with this raw sending (I expected that).

The drawbacks I have found in using the "Generic PCL Laser Printer" driver are these:

1) duplex printing in short side doesn't work. I made a workaround by using PDFJam "suffle" command to turn +90/-90 degrees the odd/even pages
2) The driver is only grayscale, no color printing using this pipeline
3) It uses all the CPU of the PC for supossedly rastering the pages before send them to printer. Not really a problem because it is pretty fast, even on a Intel Core2 4300 with only one thread.
4) Driver offers 2 printing resolutions, 300dpi and 600dpi. In 300dpi dithering is horrible. In 600dpi quality is nice, with no appreciable dithering at all.

I didn't try with Windows or OSX because I need it to be a completely unattended system, fetching the jobs from an URL described in a mail (password protected), applying user settings from that same mail to the document (n-up in {2,4,6,8,9,16}, page range, duplex) and generating a job info page with the user and cost of the job in the beggining of the printed document. My experince in scripting for these systems is low (I wonder if this can be done with commercial systems in Windows, any suggestion?). The pipeline I made runs on Debian Wheezy, with shell tools, some python in only text mode, no desktop (that was a goal) and it can be run on a low end Computer ($100) beacuse it is going to be replicated in several shops so budget is a restriction.

So, after all this tests, I blame the internal Konica-Minolta printer RIP engine. Maybe I'm wrong, but It's too slow to process PS or PCL mostly made of raster images at reasonable speed. Now I think I have found a compeltely Open Source pipeline for processing grayscale jobs.

I can send you some examples of "slow documents" (PDF) to try out in your systems, if you want.

Any other thoughts?

Thanks.
 

PressWise

A 30-day Fix for Managed Chaos

As any print professional knows, printing can be managed chaos. Software that solves multiple problems and provides measurable and monetizable value has a direct impact on the bottom-line.

“We reduced order entry costs by about 40%.” Significant savings in a shop that turns about 500 jobs a month.


Learn how…….

   
Back
Top