Stylesheet: Avoid gray body text in @media print

[Larhzu]

The body text is transparent black on white background, resulting in gray text (equivalent to #333):

body {
  background: #fff;
  color: rgb(0 0 0 / 0.8);
  ...
}

The reasons to use gray instead of black text on screen don't apply to printing. The main body text should be black (#000) when printing to avoid dithering.

Browsers might convert gray text to black when printing. Some printer drivers might do it too. So even now the gray text might print as black in some cases. It would be good to ensure good results in all cases still.

For example, Firefox 121 converts gray text to black if the gray color is specified as #333 or #666 and Print backgrounds is unchecked in the Firefox' print options. However, if the same colors are specified as transparent black text like rgb(0 0 0 / 0.8) or rgb(0 0 0 / 0.6) then the text remains gray even if Print backgrounds is unchecked. These can be tested by printing to PDF and taking a screenshot from a PDF viewer.

I'm not sure which elements should use black text when printing. h1, body, pre, code, and the various table-related elements that use rgb(0 0 0 / 0.8) should probably be black when printing. But perhaps a few other elements should be black too.

(A side note: I find rgb(0 0 0 / 0.8) (#333) too light on some displays (it hurts legibility). Somewhere from rgb(0 0 0 / 0.87) (#222) to rgb(0 0 0 / 0.93) (#121212) would look better to me. But I know it depends on the display, display brightness, user preference etc. so I don't dare to propose any changes.)

[mojavelinux]

It's not enough to change the off-black for screen to true black because there are many other colors used in the stylesheet which may appear too light when printing.

This has been discussed before and we decided not to change it. In fact, in the early days of the stylesheet, the inherited styles from Foundation forcefully turned the color of all elements to true black in print mode, which created problems. When we removed that style, users welcomed the reintroduction of color. The reasoning is stated in the following issue: #997 (comment)

The gist is that not all users use the print dialog to physically print the document. Many use it to generate a PDF. In that case, they expect the colors to be preserved. So there are two different audiences here.

What I might be open to considering is to honor a black and white (perhaps just bw) document role that would turn on additional styles to switch the off-black to true black and any use of color to an appropriate shade of gray. However, we'd first need to decide on what that role would be named. Then, someone would have to submit a PR to add the styles for that body selector to the print media query. It's not something I'm going to spend time on.

Keep in mind, you can use docinfo to provide additional print styles without any change to core. And that's usually a good place to start to understand what to put in said PR.

[Larhzu]

Thanks! I see the question isn't as simple as I had thought and I may have had wrong assumptions too.

Anyway, my intent wasn't to suggest making all text black. My point was to ensure that the main content would print as black and thus have good legibility if browser or printer driver doesn't convert gray to black automatically. The amount of text in figure captions, admonitions etc. typically isn't that much, so even if those were too light for good printing, the overall result could have been good for casual prints still.

I had assumed that black body text in print-to-PDF use would be desirable because I assumed that PDFs are typically generated so that they are good for printing (things like clickable links are just extra features on top). I hadn't used asciidoctor-pdf apart from a quick test, and now that I looked more closely I see it uses #333 by default and black text needs --theme=default-for-print. So now I realize that there are people who prefer gray body text even in PDF, thus using black body text for HTML-to-PDF conversion isn't the trivially-obvious choice like I had thought.

Keep in mind, you can use docinfo to provide additional print styles without any change to core.

Thanks! I'm already making a few other changes to the default stylesheet where docinfo alone isn't convenient enough. I'm trying to still keep it easy to stay in sync with upstream changes. A few tiny fixes/improvements were such that I thought they could make sense upstream but clearly the printing related idea isn't such.

Since I have a simple but decent solution for my taste (using CSS custom properties), I don't plan to spend more time on @media print improvements for now. Feel free to close this issue. Thanks!

[mojavelinux]

my intent wasn't to suggest making all text black. My point was to ensure that the main content would print as black and thus have good legibility if browser or printer driver doesn't convert gray to black automatically.

I understand that use case and I'm not dismissing it. The point I was trying to make is that if this improvement were to be made, it would need to be done fully. It's not enough just to change the color of the main text as that only partially addresses the issue with printing. And, as I mentioned, we have to consider the fact that not everyone wants the color to be changed. So we at least need an additional role for grayscale. When that is set, the CSS would need to modify all the elements that are colorized so they use as an appropriate amount of ink to be legible (we have to think of the dark gray of the primary text as a color).

It might even be reasonable to assume that the color change is applied outside of the print media query, which would allow the document to be grayscale even when not printing.

[Larhzu]

The point I was trying to make is that if this improvement were to be made, it would need to be done fully.

I did get your point, sorry if my message wasn't clear enough. I appreciate that you are looking for complete solutions. I understand that it's not possible to cover all use cases at the same time.

I'm happy enough with a simpler partial solution in my stylesheet customizations and I won't spend much time refining that part further. For the most polished prints there is asciidoctor-pdf anyway.

When that is set, the CSS would need to modify all the elements that are colorized so they use as an appropriate amount of ink to be legible (we have to think of the dark gray of the primary text as a color).

For what it's worth (probably not much), I feel the grays with the alpha values 0.8, 0.85, and 0.9 might be safest to become #000 when printing to paper with an unknown printer (a monochrome printer might dither grays ugly, a color printer might mix color-ink to produce grays). The alpha value isn't the only thing that differs in those selectors so flattening to black isn't a too bad compromise. The alpha 0.6 could maybe become dark gray instead of black.

With color printers, having some color in the headings might even be nice, as long as it's not too light.

There are too many possibly-useful combinations.