Printing larger files in linux

socceroos · 02-14-2010, 10:12 PM

I'm having problems printing large documents to our company printers. They all come out fine - eventually. But when printing a 10Mb PDF in Linux it sends a 100Mb+ file to the printer (the PDF contains necessary transparent objects). This is terrible for trying to get things done and means the printer is completely tied up while the Linux machine tries to send it an incredibly large file.

In Windows, the same document is sent at a size only fractionally bigger than the source document size.

Simon Bridge · 02-15-2010, 05:20 AM

Compare the 100Mb plus file with the postscript version of the same file.

To troubleshoot, we need to know how the linux computer is talking to the company printers.

business_kid · 02-15-2010, 05:22 AM

Sounds like a dpi issue. By default, windows seems often to use the crappiest resolution. Are you printing through linux at 1440x1440, and through windows at 180dpi?

socceroos · 02-15-2010, 04:16 PM

Hey fellows,

The Windows PCs are printing at 600 DPI through our PDC which forwards to the printer (Lanier MP C2500). The Linux PCs are printing at 600 DPI (only option given in vendor printer driver - PXL) through LPR (socket://bla:9100). Gradiation on both is 'fast'.

socceroos · 02-15-2010, 04:19 PM

Quote:

Originally Posted by business_kid

Sounds like a dpi issue. By default, windows seems often to use the crappiest resolution. Are you printing through linux at 1440x1440, and through windows at 180dpi?

On windows the driver reports using a DPI of 600. Is the driver making the final decision here or should I be looking elsewhere for the true DPI settings per document?

business_kid · 02-16-2010, 05:33 AM

Line up some pdf file, and print it in windows, as you insist on comparing, and note the size. For laziness put it in /tmp. Then use this line

gs -q -dBATCH -dNOPAUSE -dSAFER -sDEVICE=<your printer> -r<xres>x<yres> -sPAPERSIZE=a4-sOutputFile=/tmp/test1 somefile.pdf

you get your printer usually from gs -h. Something close is good enough.
You can then usually set resolutions that the printer might not manage. Try it on -r180x180 and work up, noting the size.

socceroos · 02-16-2010, 04:15 PM

I'm getting this:

Code:

gs -q -dBATCH -dNOPAUSE -dSAFER -sDEVICE=x11alpha -r180x180 -sPAPERSIZE=a4 -sOutputFile=/tmp/test1 intranet-report.pdf
   **** Warning:  File has an invalid xref entry:  2.  Rebuilding xref table.
Error: /rangecheck in --run--
Operand stack:
   --nostringval--   --dict:7/16(L)--   0.0   842.0
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1905   1   3   %oparray_pop   1904   1   3   %oparray_pop   1888   1   3   %oparray_pop   --nostringval--   --nostringval--   10   1   28   --nostringval--   %for_pos_int_continue   --nostringval--   --nostringval--   false   1   %stopped_push   --nostringval--   --nostringval--
Dictionary stack:
   --dict:1152/1684(ro)(G)--   --dict:1/20(G)--   --dict:75/200(L)--   --dict:75/200(L)--   --dict:106/127(ro)(G)--   --dict:275/300(ro)(G)--   --dict:24/25(L)--   --dict:4/6(L)--   --dict:21/40(L)--   --dict:3/5(L)--
Current allocation mode is local
Last OS error: 11
GPL Ghostscript 8.63: Unrecoverable error, exit code 1

socceroos · 02-16-2010, 04:20 PM

Ok, I tried the gs command with pxlcolor instead of x11alpha with all the other settings the same and here is the resulting file size:

Code:

-rw-r--r--  1 user group 204474826 2010-02-17 09:15 test1

The original PDF file size was 11.1Mb.

business_kid · 02-17-2010, 03:00 AM

That looks crazy. It doesn't just look crazy, it is crazy. It could be a 32bit bitmap, though. Ghostscript renders to ps, and then often to the individual language a printer requires. The last time I tried this, the ps output was 13k and the bjc600 output was 500k

If you type gs -h in an xterm, you see the supported printer types. Many laser printers run postscript.

Simon Bridge · 02-17-2010, 03:44 AM

Quote:

the PDF contains necessary transparent objects

How about if your test pdf does not have any of these?

socceroos · 02-17-2010, 03:58 PM

Hey guys,

I printed another PDF of about the same size (10.8Mb) that most likely doesn't use transparent objects (its the Zend Studio User Guide). Below are the results:

Code:

-rw-r--r--  1 user group 204474826 2010-02-17 09:15 test1 #Original Test: 11.1Mb
-rw-r--r--  1 user group  91765138 2010-02-18 08:46 test2 #Zend Studio User Guide: 10.8Mb

Please note, the Zend Studio User Guide contains over 400 pages whereas the Original Test contains only 28 - I imagine this affects print size. I'm sure your mind is boggling how we could stuff 11.1Mb into 28 pages on a PDF - ask marketing. All I know is that they print quickly in Windows and slowly in Linux (because of generated file size?).

Simon Bridge · 02-17-2010, 11:15 PM

The second test gives half the work to the printer yet involves about the same size PDF. This is suggesting that something in the pdfs is giving this result. None of us have been getting your figures with our own printers - but they are different printers. This suggests there is something sub-optimal about your setup.

A possibility was that the file sizes come from the way windows and linux are handling PDF files - eg. In windows you print from Adobe Reader, and in linux from Evince, file > print menu? Feature-rich PDFs created by Adobe Acrobat (try a PDF created by OpenOffice.org) may include elements that are not yet published, or may not have made it into the free software readers. But you have been testing on CLI.

You may want to see if pre-converting to postscript will help
pdf2ps filename.pdf

... print the resulting filename.ps

I notice that you said you are using the vendor driver (PXL). This is a warning sign to experienced users - the vendor may just have supplied a sub-optimal driver for linux. You have not said how it was obtained and installed.

There is a lot of information about your printer and how it can work with linux here:
http://www.linuxprinting.org/show_pr...P_C2500_LD425c
...
The suggested driver is called "pxlcolor-lanier" and it looks like they suggest a custom PPD. Also known to work with "postscript-lanier". There're lots of instructions linked from that page.

socceroos · 02-17-2010, 11:30 PM

The driver you link to is the same version as supplied from the vendor's site and is indeed the driver we are using to print with. The driver was installed when adding the printer through the GUI in most recent Gnome distrobutions.

If you have a look at the pxlcolor-lanier driver you actually refer to you will notice that by default (in the driver) it only supports printing at 600dpi. I'm aware that the printer its self supports lower resolution and that I can modify the driver - but this doesn't explain why our Windows PCs can print a high-quality 600dpi brochure with acceptable speed and size while Linux+CUPS+Driver can't.

I agree though, you would reasonably expect to have the option for lower resolutions.

To me, this problem seems less about our set up and more about ghostscripts handling of large images and certain advanced features in PDFs.

---- Below is just our perspective, if you don't care then don't read =) ----

The reason this is so important to 'us' is because we're looking to change from being a Microsoft business to an open source one - not only because its cheap, but because we value open source and want to give back. But there are a few barriers, like this one, that would greatly inhibit our day to day procedures.

Simon Bridge · 02-18-2010, 01:13 AM

Quote:

The driver you link to is the same version as supplied from the vendor's site and is indeed the driver we are using to print with.

Thanks for the clarification - it wasn't clear from your earlier statement and I didn't want to make the assumption. Now I have to rethink...

Have you used the custom PPD?
Have you tried the "postscript-lanier" driver?

Quote:

To me, this problem seems less about our set up and more about ghostscripts handling of large images and certain advanced features in PDFs.

gs is creating files consistent with what you see in the printer job queue, which suggests that the driver is converting files to postscript for printing.

Have you tried converting direct to postscript first, and printing that? (Pedantic I know, since pdf2ps uses ghostscript.) On a related note - convert the PDF into some single-layer format before printing then ghostscripts handling of PDF becomes irrelevant.

You'll still get big files - make no mistake. eg.

$ pdf2ps IMG.pdf
$ ls -l IMG*
-rw-r--r-- 1 simon simon 344102 2010-02-17 21:47 IMG.pdf
-rw-r--r-- 1 simon simon 29783750 2010-02-18 19:11 IMG.ps

So the file increases by 100x - and this is a single page invoice, mostly white space, created by scanning the paper page to a jpeg then putting the jpeg through adobe acrobat. (All too common occurrence.)

But when I hit file > print in evince, while watching the print queue, then I see the job size as 1803k - eg, only about 10x the original file size. (But, my printer is an hp.)

This is partly why I wonder about the postscript-lanier driver - it is possible that it contains postscript-specific optimisations for this printer.

The next question that comes up, then, is "what is windows doing?" to be sending

Quote:

a size only fractionally bigger than the source document

It is certainly not sending ps data to the printer!

Possibly there are legal reasons that linux cannot use the same method as windows? That would be typical.

Quote:

The reason this is so important to 'us' is because we're looking to change from being a Microsoft business to an open source one - not only because its cheap, but because we value open source and want to give back. But there are a few barriers, like this one, that would greatly inhibit our day to day procedures.

This perspective is very important - it changes the sort of advise I give you.

Moving from a proprietary to an open shop is a big deal and should be done by increments - I do this professionally.

It may be that you will ultimately have to consider changing some of your hardware, as well as your day-to-day operations, to suit the new (FOSS) paradigms. Businesses that do this (though I have been personally involved mostly in public sector migrations) usually experience a 10-20% increase in productivity in 18 months, though there is an unpredictable decrease in the short term (1-3months). Disasters are usually a matter of staff resistance.

It is unusual for businesses to be in a position to change a printer just on principle. Since you already own windows licenses, it is likely that any such decision can be put off until you'd normally replace it from attrition. You'd do this by dedicating a windows box as a print server. You send the file to windows and windows prints it. This will be very similar to what you do now.

However, it may be that pre-processing the large files you need to print will minimise the inconvenience without compromising quality.

socceroos · 02-18-2010, 06:23 PM

Hey Simon,

Thanks for your suggestions and insights. We've been slowly planning our move for 3 years now - currently piloting with a number of staff members, including me, as the guinea pigs. Its these very issues that we want to be aware of and hopefully resolve before we make a full commitment. A lot of our time has been spent waiting for certain functionality to become mature enough for business use. We have looked at changing some of our hardware - but we have some very heavy-duty printers here that we simply can't replace without upsetting many years of refinement and at substantial extra cost. The change is coinciding well with the ending of support for Windows XP and necessary server hardware upgrades.

The produced file with pdf2ps is below (test3):

Code:

-rw-r--r--  1 user group 204474826 2010-02-17 09:15 test1
-rw-r--r--  1 user group  91765138 2010-02-18 08:46 test2
-rw-r--r--  1 user group 434496868 2010-02-19 08:51 test3

As you can see, its more than double the size of the gs generated document (test1).

I then used ImageMagick to convert the PDF to 28 JPEGs with a resolution of 2479x3508 (good quality) - when trying to resize it to anything below that, the quality of the images was not suitable. The cumulative size of the generated images was just over 16Mb. I then tried using ImageMagick to convert the resulting flat images back to a postscript file. I cancelled this operation when I saw the resulting postscript file climb above 1Gb - it didn't look like stopping.

I couldn't work out how to convert multiple images back into one postscript file with gs. Should I be using something else here?