[FIX]Backgrounds should be opaque even when Print Backgrounds is off

RESOLVED FIXED in mozilla1.9alpha1

Status

()

Core
Printing: Output
P3
normal
RESOLVED FIXED
13 years ago
12 years ago

People

(Reporter: Daniel Pope, Assigned: bz)

Tracking

Trunk
mozilla1.9alpha1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Turning off the "Print Backgrounds (Colors & Images)" option* doesn't work very
well in CSS-heavy sites.

The intention of this option is to prevent printing large blocks of colour (to
conserve ink) and to increase the legibility of the text.

Because CSS positioning encourages designers to overlap elements, backgrounds
are relied upon because they serve to obscure whatever lies beneath. This is not
generally true of table-based layouts.

Turning off backgrounds currently makes backgrounds transparent. This means that
the text which was above the background can clash with elements (text or images)
which were covered by the background. It also means that potentially large
sections of replaced images can show through.

A better solution would be to make all backgrounds opaque and white.

* The prefs.js option is print.printer_<name>.print_bgcolor/bgimages

Reproducible: Always

Steps to Reproduce:
1. Turn off "Print Backgrounds (Colors & Images)" in Page Setup
2. Visit http://sinks.thetopedge.com/
3. Print or Print Preview

Actual Results:  
The top navigation bar title is illegible above the top banner.

Expected Results:  
Set all (non-transparent) backgrounds to white (opaque) rather than to
transparent when the "Print Backgrounds" option is set to false.
(Reporter)

Comment 1

13 years ago
Actually, I realise that the behaviour is as expected for background colors.

It should also happen for background images.
Created attachment 218641 [details] [diff] [review]
This should fix the background image case
Assignee: printing → bzbarsky
Status: UNCONFIRMED → ASSIGNED
Attachment #218641 - Flags: superreview?(dbaron)
Attachment #218641 - Flags: review?(roc)
OS: Linux → All
Priority: -- → P3
Hardware: PC → All
Summary: Backgrounds should be opaque even when Print Backgrounds is off → [FIX]Backgrounds should be opaque even when Print Backgrounds is off
Target Milestone: --- → mozilla1.9alpha
Comment on attachment 218641 [details] [diff] [review]
This should fix the background image case

r=dbaron, except, for the rule node changes:

 * if that bit needs to correspond to whether the pointer is null, then you need to set it in the opposite case as well, so, given that, why not move all the setting/clearing of that bit to after that if-else chain, and just do:
if (bg->mBackgroundImage)
  bg->mBackgroundFlags &= ~NS_STYLE_BG_IMAGE_NONE;
else
  bg->mBackgroundFlags |= NS_STYLE_BG_IMAGE_NONE;

But I'm still not sure why we have a bit to tell us if a pointer is null; we could just check the pointer.  But that could probably be a followup patch.
Attachment #218641 - Flags: superreview?(dbaron) → superreview+
Checked in the CSSRendering part of the patch.  I don't think we can get rid of the flag without making the check for a background image not be inline; see revision 3.72 of nsStyleStruct.h.  Let me know what you think; I can easily do that.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Leaving the flag is fine; I just prefer set/clear based on a single null-check at the end if that's what's needed.
Created attachment 219259 [details] [diff] [review]
Yeah, do that
Attachment #219259 - Flags: superreview?(dbaron)
Attachment #219259 - Flags: review?(dbaron)
Attachment #219259 - Flags: superreview?(dbaron)
Attachment #219259 - Flags: superreview+
Attachment #219259 - Flags: review?(dbaron)
Attachment #219259 - Flags: review+
Checked in the followup patch.
You need to log in before you can comment on or make changes to this bug.