Printing larger files in linux
 

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.

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.

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?

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

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?

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.

I'm getting this:

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:

The original PDF file size was 11.1Mb.

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.

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

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:

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?).

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.

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.

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?

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

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.

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):
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?

You may want to try using image magick to convert the pdfs into flat PNG files (convert the file, then flatten it so you don't have the alpha channel). Since png uses lossless compression, you may get away with a smaller resolution (no artefacts beyond the jpeg compression already used in the pdf). You also may be able to use gutenprint to handle the printing side - use the printer configuration in gimp to see if your printer is listed.

Try printing the png files one after the other - see if the behaviour of the printer is different. (Technically it should be tied up only for each page instead of waiting for 28 of them.) This is not practical for production - but there are other ways to put all the pages one at a time into the print queue. This is just a test.

I hear you about printers - I worked for PC World NZ when they migrated (from mac to PC) and ran into similar troubles. They ended up setting their print-runs overnight - which is a bummer when something goes wrong. They used an outside printing service for production runs.

How are you generating pdfs in the first place? I don't think Adobe Acrobat runs under gnu/linux. The large files may be clumsy in OpenOffice.org - requiring you split the document. LaTeX may be too rigid for what you want to produce.

I still think your short-term solution is to use a windows print server. The long term solution is to replace hardware - which the company plans to do sometime anyway. Pre-processing would be a middle-term workaround and will not produce performance that you've been used to. The printer just has to get a particular amount of information.

If I have this right:
The problem is that the printer has to wait to receive all the file before it starts printing right? It doesn't actually take longer to print once the file is sent?

I suspect the windows driver just sends compressed files to the printer, which it decompresses itself for printing. It could be that the printer starts printing before all the file is received... and the filesize reported in windows print queue is not the actual size of the job.

See - that's what happens for me when I have a big print job ... the printer starts up after the first few pages have been sent, or when the printers buffer has filled.

These are the experts - you'd be well advised to contact them. I gather there is a postscript addon for cups which is not always installed by default - this could streamline things.

There is a mamoth tutorial here which is useful for understanding how printing works - the older one, from the same page, is more technical.

[update]404 - oh dear, the older one is still there. I'd complain if I were you.

Hey Simon,

Thanks again for your help. You've been wonderful. :) I'll get in contact with the folks over at the Open Printing forums and see what light they can shed on the subject. I'll also give your last few suggestions a try. If I find a solution to the issue, I'll be sure to return here and post the answer.

Hi,
I've been trying to make a Dell 5110cn printer to work from Linux, to no avail.
I've tried sharing the printer from both a Linux and a Windows machine, and in either case, Windows clients can always print fine.
When a Linux client sends a print job that's larger than a few hundred KBs, the printer chokes and prints pages with what appear to be PostScript errors.
Can anyone help me with solving the problem.

Adan, It would be best if you started a new thread in the forums for your question as this topic is different. :)

Head over here: http://www.linuxquestions.org/questi...ux-software-2/ and click on the "New Thread" button near the top of the page.

socceroos: There is a postscript module for your printer - has that been installed?
If it hasn't then it won't handle postscript very well.

adan: welcome to LQ. I know we encourage you to post to an existing thread, and you also have a problem printing "large" files - though about 3-6 orders of magnitude smaller than the large files in this thread. (your are in kilobytes, ours are in 100s of megabytes) Since there does not seem to be anyone asking about your printer in LQ before (an unusual occurance), you will get best exposure by starting a new thread with the name of the printer and the name of your distribution as the title.

In the body, you'll need to say how you are trying to get it working and what you mean when you say it does not. Also include the extent to which it is working - eg. can you print a problem file from a linux machine directly connected to the printer?

Be aware though: your printer does not appear to be supported by Free Software drivers, so it is not really surprising if it does not work well with linux. It may be that you will just be told to contact DELL customer support. FWIW.

When you start you thread - please link to it from here, then I'll go have a proper look.