[Touch-packages] [Bug 1476705] Re: postscript printer hideously slow in some cases (pdftops)
Bruno, To be honest, I don't know what differs between the two tools, as they both come from Cairo, I assumed that pdftops was just a small wrapper around the same code as pdftocairo but with the options pre-set for PS output. I'm a Ghostscript developer, so I can't really answer specifics about Cairo - I know about the problems with the Cairo PDF output, as we've performance problems in Ghostscript with those, and have had some fairly lengthy (and heated) discussions with Cairo developers on the subject. And I have helped debug a lot of these problems with the Ghostscript output, so I can give general suggestions as I did above. If I had to guess, I would say that pdftocairo is possibly spotting that the PDF originated as a Cairo file, and is using inside knowledge of how those are constructed to convert it back into Cairo internal representation, which is then outputs to Postscript - with that level of extra information, it can probably be much, much smarter about when there is real transparency that it has to render, and when everything opaque, and remain in high level form. Whilst, pstops may be doing a simpler, one step PDF to Postscript conversion. Ideally, what you'd want to try is (if possible) to keep the ProRes (I thought it was ImageRET) mode, but still tell pdftocairo to use 600 dpi, as you then may get the benefits of more the accurate dot placement, better halftone results, and possibly better color management, whilst keeping the quicker processing of the smaller image data. It's hard to know without deep inside knowledge, but (again) if I had to guess, I would suggest that the slightly lower quality halftone screen is what's causing the slight intensity shift you mention. HP are pretty tight lipped about these technologies, but I know other such systems tend to allow the halftoning to represent more shades of the color, without losing detail (generally there is a trade off: you can approximate lots of shades, but lose detail, or have great detail, but very few shades). Chris -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to poppler in Ubuntu. https://bugs.launchpad.net/bugs/1476705 Title: postscript printer hideously slow in some cases (pdftops) Status in poppler package in Ubuntu: New Status in system-config-printer package in Ubuntu: New Bug description: With my (old) postscript printer, print a single page can take many minutes on some situations. It happens with some PDF files (not all) and Firefox printing of Google map, for example. When this happens, I observed in system monitor that pdftops is running continuously. After some manual PDF - PS conversions, I see that pdftops inflates the file size for problematic cases, but is ok for other files (size similar to the original file, or even smaller). I don't know if modern Postscript printers can handle this quickly, but it's unacceptable here and certainly not an efficient way to print those files. So I suspect that pdftops should be fixed. For example, I join a problematic pdf produced by Google Map in Firefox. I tried many conversions. As you can see, I get a much larger file (36 times) with pdftops. It is worse with pdf2ps (and it takes longer to process), so replace pdftops by pdf2ps is not an option for me. However, pdftocairo quickly produces an efficient file. I have the same success if I open the PDF file with Evince and print it as a Postscript file. I get a similar file if I print to PS directly from Google Map (Firefox). Of course these small PS files produced by pdftocairo, Evince of Firefox print flawlessly on my printer. See also Bug # 1095498 which I suspect is the same (old) thing, but I fill a new one since it doesn't seem to be printer specific. Of course, another workaround could be to use a PCL driver but no one is available for my printer (HP Color Laserjet 2605dn). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/1476705/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1476705] Re: postscript printer hideously slow in some cases (pdftops)
The problem, I suspect, is the way Cairo rights PDF files (the gmap.pdf file you attached above was created by Cairo). The Cairo *always* writes the page contents into one or more PDF transparency groups - even when all the contents are really opaque. The issue is that, due to the way PDF works (and PDF transparency in particular) the only way to be sure that all the page contents are opaque would be to pre-process each page, checking for non-opaque content, and then re-interpret the page using the information gleaned in the first pass - which would, frankly, result in an unacceptable performance drop for the vast majority of PDF files. Most interpreters I know will pre-scan the quickly accessible elements of a PDF page, and if no transparency constructs are found, will then elide the extra processing transparency requires. Unfortunately, those easily accessible elements don't contain (or, at least, don't reliably contain) the actual opacity information. So, in most cases I know, just the existence of the transparency constructs means that extra processing is enabled, regardless of the actual opacity values. Now, secondly, Postscript cannot represent PDF transparency in high level (vector etc) operations. So, the only way to get a visually accurate representation of a PDF containing transparency in Postscript is to flatten the transparency by rendering it to a sampled image - and clearly, sampled images end up being larger than vector graphics. Hence we have the result that basically every Cairo produced PDF will convert to Postscript as one or more sampled images per page. And that explains why the Postscript is so much larger than the PDF. Now, looking at the Postscript file you posted, it *appears* that the rendering for transparency flattening is being done at 1200dpi which is, frankly, ridiculous for a couple of reasons. First is, your printer has a maximum physical resolution of 600dpi (the ImageRET modes provide enhanced quality, claimed to be equivalent to 2400 and, IIRC, 3600 dpi, but the printer is still a 600 dpi printer). Secondly, our experience with Ghostscript's Postscript output, is that many printers are much, *much* faster at upsampling images than downsampling. So, my first suggestion would be to poke around the CUPS dialogues and/or the PPD, and see if you can drop the claimed resolution of the printer to at most 600dpi and, frankly, I'd even try 300 dpi. As a rule of thumb, in the printing world, it's generally claimed that dropping continuous tone, sampled image resolution by 50% from the physical resolution results in almost no visible loss of quality. Where that falls down, in cases like this, is because there is text involved, and the small details inherent in text shapes may well suffer visibly. Another thing we've found with the Postscript output from Ghostscript is that many printers are very, very slow at decompressing data, so if you can find an option to avoid compressing image data, that *might* make a difference - but that is highly printer dependent. I'd like to take this opportunity to rant (again): this kind of thing is the reason that PDF is such poor, poor choice as a print spool format. PDF has a *hugely* rich imaging model, *far* more so than Postscript, PCL5/PXL or any of the proprietary page description languages (PDL), which means for almost any low/midrange PDL based printer, there is a very high chance that the PDF content cannot be converted to a high level, vector representation, and must be rendered and sent as sampled images (bitmaps). Perhaps a PDF/A or PDF/X variant would be a better choice.. And I'm sure someone will point out that more and more printers are supporting direct PDF printing, but that really just moves the bottleneck: PDF transparency is (over!) complex, and is extremely processor and memory intensive. So a low/mid range printer, with limited memory and processing power, is going to struggle to print a file like these ones. In truth, many such PDF printers get around this by either not supporting transparency at all, or supporting only relatively trivial subset of the full PDF transparency model. Also, with more and more applications integrating Cairo to do their PDF output, with the transparency problems outlined above, the situation is only set to get worse. /rant Anyway, as I said, look into adjusting the resolution, and possibly compression settings, and let us know how you fare. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to poppler in Ubuntu. https://bugs.launchpad.net/bugs/1476705 Title: postscript printer hideously slow in some cases (pdftops) Status in poppler package in Ubuntu: New Status in system-config-printer package in Ubuntu: New Bug description: With my (old) postscript printer, print a single page can take many minutes on some situations. It happens with some PDF files (not all) and Firefox printing of Google map, for
[Touch-packages] [Bug 1366743] Re: Ubuntu 14.04 only prints LibreOffice Docs
Sorry, but that printout file is still the Poppler created one. I'm afraid I'm going to need Till's input on this as my knowledge of cups is limited (and now exhausted) - I only really do the Ghostscript end of things.. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1366743 Title: Ubuntu 14.04 only prints LibreOffice Docs Status in “cups” package in Ubuntu: Incomplete Bug description: I use Ubuntu 14.04, a Logilink Fast Ethernet Printserver and a HP Color Laserjet 2550L. Under Ubuntu 12.10 everything worked fine and I could print any file. The printer is connected via a USB to the Printserver and adressed via HP Jet Direct. As already said, everything worked fine under 12.10 and I didn't change any settings on the printserver. I use the ubuntu tool for installing the printer, as a normal user not su. Searching the network, for network printers offers me three possibilities for adressing the printer. HP Jet Direct, IPP and LPD/LPR. I tried all of them with the same result. I use the drivers from the Database, not surprisingly HP/Color Laserjet 2550/HP Color Laserjet 2550 Series Postscript [en] (recommended). After installing the printer the first thing that fails is the Testpage. The ubunut printer spooler tells me that the job is in progress and the printer starts to blink to tell me that he is receiving input. Unfortunatly the job never starts or gets finished. After blinking quite a while the printer stops an nothing happes. Interestingly, after canceling the job on my computer and a restart of the printer, the printserver and my computer, I can open libre office writing Hello World go to print and the printer starts immediately and prints the correct result. But this only works for libreoffice and only with text, as soon as there is an image in the document it doesn't work. I can't print any pdf or even from gedit. Nothing works. Always the same as with the Testpage. Printer starts to blink but nothing happens. lsb_release -rd Description: Ubuntu 14.04.1 LTS Release: 14.04 Thanks for Help. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1366743/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1366743] Re: Ubuntu 14.04 only prints LibreOffice Docs
Odd, that printout file is from the cairo/poppler pdftops filter, rather than the Ghostscript one that I deal with. If you can repeat the tests after running: lpadmin -p HP-Color-LaserJet-2550 -o pdftops-renderer-default=gs And post your results and another printout file. If you want to, you can open the printout file in a text editor and look at the comments in the first 20 lines or so, and see whether it was created by Poppler or Ghostscript. Thanks I'll leave it to Till to decide whether to contact the appropriate Cairo/poppler folks. Chris -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1366743 Title: Ubuntu 14.04 only prints LibreOffice Docs Status in “cups” package in Ubuntu: Incomplete Bug description: I use Ubuntu 14.04, a Logilink Fast Ethernet Printserver and a HP Color Laserjet 2550L. Under Ubuntu 12.10 everything worked fine and I could print any file. The printer is connected via a USB to the Printserver and adressed via HP Jet Direct. As already said, everything worked fine under 12.10 and I didn't change any settings on the printserver. I use the ubuntu tool for installing the printer, as a normal user not su. Searching the network, for network printers offers me three possibilities for adressing the printer. HP Jet Direct, IPP and LPD/LPR. I tried all of them with the same result. I use the drivers from the Database, not surprisingly HP/Color Laserjet 2550/HP Color Laserjet 2550 Series Postscript [en] (recommended). After installing the printer the first thing that fails is the Testpage. The ubunut printer spooler tells me that the job is in progress and the printer starts to blink to tell me that he is receiving input. Unfortunatly the job never starts or gets finished. After blinking quite a while the printer stops an nothing happes. Interestingly, after canceling the job on my computer and a restart of the printer, the printserver and my computer, I can open libre office writing Hello World go to print and the printer starts immediately and prints the correct result. But this only works for libreoffice and only with text, as soon as there is an image in the document it doesn't work. I can't print any pdf or even from gedit. Nothing works. Always the same as with the Testpage. Printer starts to blink but nothing happens. lsb_release -rd Description: Ubuntu 14.04.1 LTS Release: 14.04 Thanks for Help. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1366743/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1366743] Re: Ubuntu 14.04 only prints LibreOffice Docs
As the file you have is PDF, you should be trying: lpr -P printer -o psdebug file.pdf or lp -d printer -o psdebug file.pdf If that works, let us know. If not, you need to follow the instructions starting here: https://wiki.ubuntu.com/DebuggingPrintingProblems#Getting_the_data_which_would_go_to_the_printer And then that should give you a Poscript file which, hopefully you can then use the instructions to send unfiltered to the printer. If the printer does not print, then attach that Postscript file here, and we can hopefully start the (usually lengthy!) process of debugging it. OTOH, if sending the file unfiltered works (unlikely!) , tell us that, too. Finally, once you've done all that, as a workaround, you can do: lpadmin -p printer -o pdftops-renderer-default=pdftops and try printing. Again let us know whether that works, doesn't work, or whatever. Chris -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1366743 Title: Ubuntu 14.04 only prints LibreOffice Docs Status in “cups” package in Ubuntu: Incomplete Bug description: I use Ubuntu 14.04, a Logilink Fast Ethernet Printserver and a HP Color Laserjet 2550L. Under Ubuntu 12.10 everything worked fine and I could print any file. The printer is connected via a USB to the Printserver and adressed via HP Jet Direct. As already said, everything worked fine under 12.10 and I didn't change any settings on the printserver. I use the ubuntu tool for installing the printer, as a normal user not su. Searching the network, for network printers offers me three possibilities for adressing the printer. HP Jet Direct, IPP and LPD/LPR. I tried all of them with the same result. I use the drivers from the Database, not surprisingly HP/Color Laserjet 2550/HP Color Laserjet 2550 Series Postscript [en] (recommended). After installing the printer the first thing that fails is the Testpage. The ubunut printer spooler tells me that the job is in progress and the printer starts to blink to tell me that he is receiving input. Unfortunatly the job never starts or gets finished. After blinking quite a while the printer stops an nothing happes. Interestingly, after canceling the job on my computer and a restart of the printer, the printserver and my computer, I can open libre office writing Hello World go to print and the printer starts immediately and prints the correct result. But this only works for libreoffice and only with text, as soon as there is an image in the document it doesn't work. I can't print any pdf or even from gedit. Nothing works. Always the same as with the Testpage. Printer starts to blink but nothing happens. lsb_release -rd Description: Ubuntu 14.04.1 LTS Release: 14.04 Thanks for Help. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1366743/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
