1432750 - printed to PDF printers, page background is not transparent.

Status: UNCONFIRMED

(Core :: Printing: Output, defect, P3)

Description

[Glenn Linderman]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20180103231032

Steps to reproduce:

Made a small test file, containing only a header "This is a test".
From Firefox, printed to Adobe PDF Distiller, and to PDFill PDF Writer. Also imported into M$ Word, and printed to both PDF printers.


Actual results:

Tried to use the file as a watermark in PDFill Editor and PDFtk. Because it should be transparent, it should be able to overlay other PDF files without obscuring them.


Expected results:

The overlaid content was obscured by the Firefox-generated PDF files, producing a page that was all white, except for the text from Firefox. The ones from Word could be used successfully, just adding the text at the top to the combined PDF file. This seems to indicate that Firefox, but not Word, prints a background color to the page. Experimentation showed that there is a transparent margin on the page from Firefox, about half an inch. Examination of the PDF file itself discovered graphics operations filled a box with white ink that covered the center 7.5×10" of the page.

Reading the CSS specs, I find that the background-color should have an initial value of transparent; but to be sure I also tested with an explicit

* { backgronud-color: transparent; }

and got the same results. I tried both checked and unchecked in the Page Setup settings for "Print background colors and images".

I found references to browser.display.background_color and to the preferences for colors; neither seem to provide an option for transparency. Still, the default browser background color should not be included in printing. What gets printed should have a transparent background, unless, I guess, the option to "print background colors and images" is selected _AND_ the page has a background image or color (Mine do not).

This is much reduced test case from the actual situation that was first encountered.

Obviously this problem isn't terribly noticeable to people that print to white paper, but when printing to PDF, and doing further manipulations of the PDF file, it is very noticeable. Since it also seems to be non-standard, and non-conforming to the "Print background colors and images" directive being unchecked, it seems it is a bug. I looked at the content of the PDF output, and was able to find directives in the file to color the paper white.

It prevents a PDF file from being used as a watermark for another PDF file, and it prevents combining PDF pages that have complementary content from different sources into a single page (my real application).

Comment 1

[Jet Villegas (inactive)]

[ Triage 2017/02/20: P3 ]

Comment 2

[Glenn Linderman]

Googling for possible workarounds for this bug, I ran across a help request <http://nuance.custhelp.com/app/answers/detail/a_id/6591/~/creating-a-pdf-does-not-retain-background-colors-and-images> for the opposite "problem": that some programs produced transparent PDFs with no background. Particularly mentioned with M$ products: Word and IE. While I don't use the latter, I do some testing in Edge, so I tried printing my pages to PDFill from Edge, and then combining them, and it worked. So by default, it seems that Edge does not print a white background like FF does. I reran the same test in FF, and it still does (no surprise, no action on this bug yet).

This isn't really a workaround for me, at least not yet. Edge has limited ability to choose margins, and presently doesn't support all the "standard" features that am using. It also renders the same HTML + CSS with different spacing than FF. But it does show that it is (1) possible (2) interpreted-by-M$-as-correct to produce transparent backgrounds for transparent HTML... they didn't choose to change that behaviour from IE (as reported above) when they were trying to become more standard.

Anyway, it is additional information related to this issue.

Comment 3

[Glenn Linderman]

Oh, and I also spent some hours a few weeks ago trying to look at the source code for Firefox to figure out where the big white background rectangles might be created, thinking perhaps I could create a custom version of FF that didn't create them for my own use, but I could barely follow the logic flow, and I didn't find any obvious spot where background rectangles were created, and I've never attempted to build FF, so without finding "the spot" or even a likely candidate, I didn't think it was a profitable use of time to try to build a private version.

I'm not averse to running a private version, or an extension that would cure this problem, but I haven't found that any of the PDF-creating extensions that I've tried address this: certainly not in their feature descriptions, and not in the several I tried.

Pointers to "the spot" might inspire additional research on my part.

I did analyze the output PDF and could find and manually edit out the big white rectangles. Probably I could script that process for my particular needs far faster than I could, on my own, find "the spot" and patch FF to do the right thing.

Comment 4

[Glenn Linderman]

Thinking about this more, as it gets closer to the time when I either have to fix this bug (with help, I don't have the background to do it alone in a reasonable time frame), or to write a PDF post-processor for the output files, I decided to check the standards again.

The earliest of CSS specs declares that the initial value for background-color should be transparent: https://www.w3.org/TR/CSS1/#background-color And so does the latest I can find: https://www.w3.org/TR/css-backgrounds-3/#backgrounds

It is reasonable, in this day of windowed GUI interfaces, that a user agent would want to have a (by default) white background to separate the content of its display from the background noise of the desktop and windows it overlaps. I can also think of useful reasons that a user may wish to configure that differently in certain circumstances, even making that transparent, and letting the other windows or the desktop be the background for the HTML presentation. But in any case, the window background should not be considered part of the HTML presentation, nor should it be included (by default) when printing.

Comment 5

[Dan Callahan [:callahad]]

Hi Glenn, sorry for the delay in following up from your comments on the Hacks blog.

If I'm understanding your use case correctly, you're trying to generate a watermark PDF from an HTML document by printing it in Firefox to a virtual printer.

This works correctly in Edge, but fails in Firefox as the resulting PDF includes an opaque white box behind the page content.

1. Is that correct?

2. Are you able to test the same using other platforms? (For example, macOS has native print-to-PDF functionality.)

3. Could you please upload a examples for me to mess around with? Especially: Two identical watermark PDFs from the same virtual printer, but one printed from Edge and one from Firefox, and a single base PDF to attempt to combine them onto. Instructions for using pdftk to accomplish the watermarking would also be helpful.

Comment 6

[Glenn Linderman]

Attachment: Some text on the left side of a page

Comment 7

[Glenn Linderman]

Attachment: some text on the right side of a page

Comment 8

[Glenn Linderman]

Attachment: fl.html printed to PDF using PDFill printer driver (any PDF printer should do)

Comment 9

[Glenn Linderman]

Attachment: fr.html printed to PDF using PDFill printer driver (any PDF printer should do)

Comment 10

[Glenn Linderman]

Attachment: fl.html printed using PDFill from Edge

Comment 11

[Glenn Linderman]

Attachment: fr.html printed using PDFill from Edge

Comment 12

[Glenn Linderman]

Attachment: fl+fr.pdf adding fr as watermark to fl using pdftk

Comment 13

[Glenn Linderman]

Attachment: fl-Microsoft Edge plus fr-Microsoft Edge.pdf as watermark using pdftk

Comment 14

[Glenn Linderman]

So these are just test files, not the files of interest, which are far more complex. But they serve to demonstrate the issue.

fl.html and fr.html are the source files.... same file, one with the header floated left and the other with the header floated right.

fl.pdf and fr.pdf are the output of printing the source files from Firefox (release track, current version, done today, with the same results as a year ago). Output PDF print driver was from PDFill (but testing a year ago by a friend that had Adobe Distiller produced the same sort of results; 3 PDF print drivers produced the same results then, PDFill was one of them). So we concluded the issue was with Firefox, not the PDF print driver, especially when we got different results from Microsoft Edge, with all 3 print drivers.

fl-Microsoft Edge.pdf and fr-Microsoft Edge.pdf are the output of printing the source files from Microsoft Edge, through the PDFill PDF printer driver.

Then I used the pdftk Server command line program to add fr as a watermark to fl. Because fl doesn't have a transparent background, fr doesn't shine through.

Then I used the pdftk Server command line program to add fr-Microsoft Edge as a watermark to fl-Microsoft Edge. As demonstrated, both the left and right text shows up.

Using the files in various combinations, one can demonstrate that both files from Microsoft Edge have transparent backgrounds, but both files from Firefox have white backgrounds.

Earlier testing, IIRC, seemed to indicate that the white background does not cover the margin area, just the content box area.

Here is more info about pdftk. The PDFill program can also be used to do similar operations, with similar results, but this testing used pdftk to combine the files.

From the pdftk server manual https://www.pdflabs.com/docs/pdftk-man-page/

background < background PDF filename | - | PROMPT >

Applies a PDF watermark to the background of a single input PDF. Pass the background PDF’s filename after background like so:

pdftk in.pdf background back.pdf output out.pdf

Pdftk uses only the first page from the background PDF and applies it to every page of the input PDF. This page is scaled and rotated as needed to fit the input page. You can use - to pass a background PDF into pdftk via stdin.

If the input PDF does not have a transparent background (such as a PDF created from page scans) then the resulting background won’t be visible — use the stamp operation instead.

Here are the exact commands used today to combine the files for this demonstration. The pdftk installation was from a year or more ago, but I don't expect differences with today's version if there have been updates, because the problem is in the files generated by Firefox, from all indications.

"c:\program Files (x86)\PDFtk Server\bin\pdftk.exe" fl.pdf background fr.pdf output fl+fr.pdf

"c:\program Files (x86)\PDFtk Server\bin\pdftk.exe" "fl-Microsoft Edge.pdf" background "fr-Microsoft Edge.pdf" output "fl-Microsoft Edge+fr-Microsoft Edge.pdf"

Comment 15

[Glenn Linderman]

Oh, the margins and maybe the layout defaults between Firefox and Edge are apparently different, the text doesn't appear in exactly the same places in the PDF outputs from the two browsers. I'm not concerned about that, I didn't attempt to make them identical in that way.

Any other questions, I'm happy to try to answer.

Comment 16

[Glenn Linderman]

Forgot to answer your questions specifically. All the above was in response to question 3.

The others are easy to answer, but not real helpful.

1. Yes

2. No

3. See comments 14 & 15.

Comment 17

[Dan Callahan [:callahad]]

Using the PDFs provided, I can confirm your experimental results: the Edge PDFs have a transparent background, the Firefox ones do not.

However, I'm not able to generate PDFs with transparent backgrounds in any of the browsers I tested.

I tested the following browsers, which all produced opaque PDFs:

• Firefox on Linux
• Firefox on macOS
• Chrome on Linux
• Chrome on macOS
• Safari on macOS

All with the system PDF printer.

That leads me to believe that the Edge's behavior might actually be aberrant, and I'd expect it to match Chrome's once Microsoft finished switching engines later this year. :-(

This creates a pretty high barrier to changing the existing behavior (if that's even under our control; these assumptions might be baked into the system PDF printers on other platforms), as we'd have to convince ourselves that the prevailing practice was clearly incorrect, and that there would be significant user benefit (and minimal user harm) by deviating from other browsers' behaviors.

Though that's only speculation on my part. I'd want to hear from a layout module peer for anything definitive.

Comment 18

[Glenn Linderman]

First, Dan, thanks for the extra testing, and response to this issue, which had languished for a year. I had actually determined that Chrome on Windows also produces a white background. I have no ability to test on other OS.

Regarding the results of your testing, it is no surprise that Firefox and Chrome have consistent behavior from one OS to the next. Windows doesn't have a "system PDF printer" as far as I'm aware, but I guess it is convenient that the others do. I don't think the issue is in the PDF printers, but in the broswers.

Obviously you couldn't test Edge or IE on the other OS. Yes, I fear that a Chromium-based Edge may lose its standard-corforming transparent background, I have a friend that uses the insider builds, and as soon as it is released to that channel, I hope to have him test it and report to me, and to M$, if the behavior has changed. While M$ hasn't historically been known for slavish adherence to standards, it seems in this case they did conform, whether by accident or design.

The only really new information your testing provides is that about Safari.

The specs are very clear that the default background is to be transparent, regardless of what any browsers actually do. Because many web pages are not printed, and because most people print on white paper, and because most PDF printer drivers would know that most printers don't even have white ink, and so don't instruct them to do white fills, this issue is easy to overlook, unless trying to overlay PDF files as I tried.

Regarding the barrier to changing existing behavior... few people have ever noticed the difference between Edge & IE (which correctly produce transparent backgrounds) and the other browsers (which incorrectly produce a non-standard-conforming white backgrounds). I strongly suspect that few people would ever notice the difference between the current erroneous behavior of Firefox producing an erroneous non-standard-corforming white background, with a changed behavior of Firefox producing a standard-conforming transparent background, if you were to fix this issue.

On the other hand, there is a middle ground: give the user control of the background color, both for printing and for display. There are already settings to choose a color, but not transparency. To avoid backwards incompatibility with the past and current erroneous non-standard conforming behavior, you could leave the default as opaque white, and simply document how to achieve a standard-conforming transparent background via browser settings (once it is made possible).

Comment 19

[Glenn Linderman]

Another point: which is more useful, a white background, or a transparent background?

1. It takes work by browsers to generate a white background.
2. It takes space in PDF files to describe the white background.
3. White backgrounds prevent overlay of documents.
4. It takes work by printer drivers to ignore white backgrounds.

Transparent backgrounds have none of these deficiencies.

Are there any benefits to white backgrounds?

Comment 20

[Glenn Linderman]

The "Correct answer" on this page: https://forums.adobe.com/thread/2190851 makes an interesting statement:

"PDF files do not have the concept of a “background color” for a page. Most applications simply layout the content of a page on a “blank” background, i.e. one that has no color at all, which is very different than an explicit white background. A white background would need to be defined as a rectangle filled with white covering the entire printed area and positioned behind any other content."

Sounds like the default background color for PDF files is transparent, similar to the HTML standard. So to achieve a white background, it is necessary to emit those big white rectangles, but it is not at all clear that a white background should be achieved, nor that the big white rectangles are appropriate, for either HTML or PDF.

The answer indicates that finding such a white background in a PDF file would be a surprise, thus making it hard to change the background color, as the second part of the question asks (although the first part of the question is asking something far more complicated).

Comment 21

[Glenn Linderman]

Continuing the thoughts in Comment 19:

5. It is far easier to add a background to a transparent PDF than to subtract opaque white rectangles. The pdftk and PDFill tool sets (and others) both allow overlays of watermarks, which could be solid color, picture, watermark, or any other type of background, but doing so only works if the starting PDFs have no background, or a transparent background.

Comment 22

[Glenn Linderman]

As semi-expected, the early version of Edge-based-on-Chromium has a white background. Bug will be reported soon. I'll attach the files, but they aren't worth much.

Comment 23

[Glenn Linderman]

Attachment: fl.Chromium-Edge.pdf

Comment 24

[Glenn Linderman]

Attachment: fr.Chromium-Edge.pdf

Comment 25

[Glenn Linderman]

Attachment: fl.Chromium-Edge+fr.Chromium-Edge.pdf

Comment 26

[Glenn Linderman]

The regression in Chromium Edge has been reported to M$ by my friend through the insider program.

I discovered that my ancient version of Adobe Photoshop honors the transparency (or not) of PDF files, and by using it confirmed that the PDFs produced by Firefox have transparent margins, but the ones produced by Chrome and Chromium Edge do not, and that the ones produced by released IE & Edge have fully transparent backgrounds.

So it seems that current Firefox behavior is different than current IE behavior, and different than Chrome behavior.

So compatibility with Chrome is not a reason not to make changes to Firefox in this regard, because it isn't.

Compatibility with a standard is a far superior position that compatibility with Chrome.

Comment 27

[noyee]

im sorry

hope it can help,
for printer drivers can be visited here: https://www.my-hpdrivers.com

thank you