2

Setup: pi4B 4G Raspbian Buster on SDcard (128G) Chromium Version 74.0.3729.157 (Official Build) Built on Raspbian , running on Raspbian 10 (32-bit)

Be sure to also read the update at the end of this question.

I frequently print my Chromium web pages with ctrl-p and select

save as PDF

Many of the web pages show tables of information in which the columns or rows or cells may be color coded in order to add more usefulness to the table data. When the preview for the save as PDF is on screen, on most pages (but not all), all the color coding is gone and has become monochrome. The resulting PDF file(s) are also without any color at all. If I then print any of these files to a color inkjet, the output has no color at all. The pages that do retain color are rare, and sometimes still lose some of the color encoding.

Here is an example url:

https://elinux.org/RPi_USB_Wi-Fi_Adapters

I would like to be able to PDF such web pages with the color information intact instead of lost, all pages, just as I see them in the browser. What settings, options, preferences must I change in order to accomplish this?

I would rather not have to save the page as html and then open it on some other computer connected to a color inkjet. I much prefer to be able to create the full color PDF from within Chromium on Buster, and have that color PDF be truly transportable, in color.

Is this simple pilot error, or, related to Chromium, Buster, or some other cause?

UPDATE

@Botspot posted a response which made a good point about settings when printing. I had tried those changes, and though they did make a slight change to the resulting PDF, they did not solve the problem fully. So you may consider his response, and our comments to it, part of this OP. Those results lead me to suspect that a full proper solution may require setting up a CUPS printer with a more correct ppd or filter or whatever CUPS might call the configuration file. A better ppd for accurate PDF output would be preferred, but I realize I may need to compromise with some other ppd, as long as there is a practical way to have the resulting PDF. Back in the 1980's (I think) Adobe released the Acrobat suite which included an Acrobat PDF ppd for use in the print dialog box on Macintosh systems. As Desktop Publishing matured, and Apple included a PDF option in their system print dialog boxes, the Adobe ppd remained superior in accuracy for creating PDFs. Perhaps something like that is what is needed here, where the Raspbian Debian PDF option is not yet sufficiently developed for 100% accuracy in objects, positions and color information? Having some procedure for selecting a 'good' ppd CUPS configuration would probably be easier than printing to a ps or eps file, and then having to convert that to a PDF by running it through some type of RIP. I am hoping for a solution matching the pi's low cost, and a solution that is simple to use each time one prints (even if setting up the 'one time' configuration may take a bit more time). I am hoping this will benefit everyone who frequently archives research information by creating PDFs of web pages. The current PDF option in the system, and in chromium, for the simplest of purposes, mostly works, but printing the average web page to PDF, these days, has become more than the simplest of purposes. Too often I have needed to jump over to a different system in order to get a reasonable readable PDF. I'm hoping we can configure the pi (debian Raspbian) to make using another system just for PDFing web pages, unnecessary.

So, a part two of this question becomes:

As an alternative, how would one use Linux CUPS printing instead, with a better choice of ppd, to get PDF output that actually does correctly retain all the objects and color information, in place, on the page(s) of the resulting PDF?

2

Make sure Chromium knows to include graphics. Mine was off by default.
enter image description here
Alternatively, use Ctrl+Shift+P and maybe you'll get better results.

  • Tried both of those. I should have said that, but it is helpful. That had helped a little on some pages, but not at all on others. THat is why I gave a link to an example where none of that would work. If it works for you on that page, please let me know. Do try it on your system. – always_learning Dec 4 '19 at 4:01
  • 1
    I saved as PDF, and the little penguin is not visible. But when scrolling to the bottom of the document there is some green shaded cells in a table, and a full-color picture of a RPi 1. What does it look like to you? – Botspot Dec 4 '19 at 4:53
  • Background graphics and headers and footers selecting in all the following tests... Thru chromium print, the Edimax picture is color and the references footer is color with pi. No Penguin. No color in the body tables. Thru system dialog: No penguin, Edimax picture and pi picture are color. No color anywhere else, and some gibberish in the reference section. Viewed with pdf viewer and okular, no difference. What is your system version? – always_learning Dec 5 '19 at 0:51
  • 1
    @always_learning, that's exactly the same as what I observed. Chromium-browser v74 – Botspot Dec 5 '19 at 14:03
  • I suspect the solution may involve setting up a CUPS printer, perhaps with a superior PDF ppd or filter or whatever CUPS might call it. I will edit my OP later, to include the hope of a CUPS solution. – always_learning Dec 5 '19 at 14:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.