1631449 - Platform support for adding a 'black and white' color mode option to print preview

Status: RESOLVED FIXED

(Core :: Print Preview, enhancement, P2)

Description

[Jonathan Watt [:jwatt]]

The new print preview design has a "Color mode" option with the options "color" and "black and white". We should figure out what we need to do to support this mode.

The naive/simplest thing to do would be to apply filter: grayscale(1) to the document/pages. However, that may or may not be performant enough. If it is not [in some scenarios] then we may need to investigate the performance issues, or whether we need some other approach.

(I'd note that Chrome reconstructs the print preview when the user enables/disables "black and white", but that's probably simply because they generate a PDF and display that using PDFium, whereas we display a paginated document at the stage prior to generating a PDF/print. That is, Chrome's behavior shouldn't be taken as an indication that we need something more complex than filter: grayscale(1).)

Comment 1

[quasicomputational]

It'll need to be a bit more complicated than that, because the values of some media queries will change (color, monochrome, possibly some others). Not by much, though!

Comment 2

[Jonathan Watt [:jwatt]]

Thanks for pointing that out.

We only currently support 'color' and 'monochrome' (not 'color-gamut' or 'color-index'), but presumably only for screens since we don't yet seem to support either of those during print output, based on my quick testing. We would need to apply those to the actual print output if we're going to apply them in the print preview output, since print preview should try as best it can to faithfully show what is going to be printed. Fixing up our printing to apply 'color' and 'monochrome' is out of scope for this bug though (we're just enabling reimplementation of the "Black & White" checkbox in the print dialog in the new UI, here).

Comment 3

[Daniel Holbert [:dholbert]]

apply filter: grayscale(1) to the document/pages. However, that may or may not be performant

One thought on an optimization (though I don't know enough about our filter implementation to know for sure whether this would help):

Hypothetically, if we're showing print-preview of 20 pages and things aren't performant because we're filtering all 20 pages: we could conceivably just apply the filter at the level of the scrollable container, so that it only covers the piece of the print preview output that is currently being viewed (~1 page). Or something like that.

(Though: maybe filters already work kinda like that under the hood anyway, i.e. maybe they only actively spend time doing filter operations on what's currently visible/painted? Not sure.)

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1631449 - Apply a grayscale filter to pages when monochrome. r=jwatt

This hooks the "monochrome" media query and co to the
nsIPrintSettings.printInColor setting.

This print setting we're using is not exposed in the print preview UI,
but you can test it setting the print.print_in_color preference to
"false", and then print preview will correctly show up greyscale'd.

Once this lands, the UI folks just have to use it as they see fit :)

I would've liked to add a proper rendering test, but the print reftests
check only whether the PDF text matches.

I could add a test to printpreview_helper.xhtml, but I'm refactoring
that file in bug 1648064 so I'd rather wait a bit and add it in a
separate bug. The test for the media feature should make sure that we
test that code path at least.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a7018dce0762
Apply a grayscale filter to pages when monochrome. r=jwatt

Comment 6

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/a7018dce0762