Closed Bug 90434 Opened 23 years ago Closed 19 years ago

[FIX] printing selected text leaves dark background

Categories

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

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: mail-mozilla.org, Assigned: MatsPalmgren_bugz)

References

()

Details

(Keywords: fixed1.8.1, testcase)

Attachments

(7 files)

Selecting text and then printing it adds a background. In effect, it appears
that the text is still selected when it is printed.

Build 2001062815 on Win98. Printing to an Epson Stylus Color 500.

Reproducing:

1. Visit a site. In my case it was http://www.theregister.co.uk/content/6/20311.html
2. Select text to print. Here I merely selected the center column.
3. On the File menu choose 'Print'. Under 'Print range' click 'Selection'.
Attached file HTML not affected.
I can confirm this bug on Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4+)
Gecko/20011002. I'm using a Lexmark PCL/PostScript printer, although I don't
think that matters.

Through trial and error (and printing a lot of test pages), I've been able to
figure out what HTML code causes the problem. The problem is that when selected
text is printed with print | selection, the black text appears on a dark
background. 

I added three attachments. If you open the attachment called "HTML affected by
the bug" in Mozilla, select some of the text, go to File | Print, click on
"selection," and hit "ok," you will get hardcopy output that looks similar to
that in the attached graphic file. (The graphic file was provided by the reporter.)

On the other hand, if you open "HTML not affected," select some of the text, go
to File | Print, click on "selection," and hit "ok," the hardcopy will not
resemble the graphic file, but will be simply black on white text. This is the
correct behavior.
Whenever two TD elements are used in the same table with different "align"
attributes (like center, and justify), this bug will likely pop up. The HTML
attachments are short and should show the exact difference between what works
and what doesn't.

I know that printing web pages is not necessarily the best use we can make of
modern technology, and that putting two TD elements in the same table with
different attributes makes no sense, but still. Mozilla should display the text
in the same way that it prints it. Fixing this problem should work out one minor
kink in the current implementation.

Please enjoy this information. A small tree died to make it possible.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reassigning to Rod
Assignee: dcone → rods
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.9
Attached file more reduced testcase
Very strange, the align=justify is what does it in a table.
Target Milestone: mozilla0.9.9 → mozilla1.1
Priority: -- → P2
Target Milestone: mozilla1.1 → Future
*** Bug 219281 has been marked as a duplicate of this bug. ***
*** Bug 158759 has been marked as a duplicate of this bug. ***
Another illustration from bug 158759
http://members.aol.com/DrMWEcker/mathhole.html

Hardware/OS -> All/All
Severity -> major
Severity: trivial → major
OS: Windows 98 → All
Hardware: PC → All
I have encoutered the same problem, with Mozilla 1.5: When I select a text for
printing, the selection is highlighted on the screen, but I do not want it to be
highlighted on the pape!
I have noticed that:
-> Text with bullets is not highlighted,
-> The first normal paragraph after a bullet list is not highlighted,
-> The first title after a bullet list is highlighted.
.
Answer: Bugzilla@delyon.net.
Keywords: testcase
*** Bug 232289 has been marked as a duplicate of this bug. ***
*** Bug 239755 has been marked as a duplicate of this bug. ***
Note, as with my comments on Bug 239755 - this might be considered a feature,
not bug, when considering printing whole document or "pages from..to". With
"Print Selection" it's definitely a bug (whole printout gets highlighted, not
just selected piece the user might want standing out)
Assignee: rods → core.printing
Status: ASSIGNED → NEW
QA Contact: sujay
Attached image example for the bug
while nobody seems to deny the status of bug, I tried to reproduce this bug
whith Internet Expolorer 6 , it produced a correct printing without grey
background, while mozilla 1.7.2 produces the grey background.
*** Bug 255852 has been marked as a duplicate of this bug. ***
*** Bug 263026 has been marked as a duplicate of this bug. ***
it could be a feature after all: if you want to highlight some information in
the printout, you can select it before to print the page.
NOT for "print range= selection".
*** Bug 286681 has been marked as a duplicate of this bug. ***
*** Bug 293435 has been marked as a duplicate of this bug. ***
*** Bug 297474 has been marked as a duplicate of this bug. ***
*** Bug 298586 has been marked as a duplicate of this bug. ***
This problem also occurs with pages without TD elements. Exemple :
http://www.recul-democratique.org/article.php3?id_article=95
This website is made with Spip, a CMS. Other websites made with Spip, like
http://www.poureva.be/article.php3?id_article=223, are concerned too. These two
sites didn't customize a lot the Spip standard installation.
Assignee: printing → mats.palmgren
Summary: printing selected text leaves dark background → [FIX] printing selected text leaves dark background
Target Milestone: Future → ---
Attached patch Patch rev. 1Splinter Review
Attachment #195133 - Flags: superreview?(bzbarsky)
Attachment #195133 - Flags: review?(bzbarsky)
Comment on attachment 195133 [details] [diff] [review]
Patch rev. 1

r+sr=bzbarsky.

And yes, GetSelectionColors already does a EnsureDifferentColors() as needed,
so you can probably remove that line in PaintUnicodeText.
Attachment #195133 - Flags: superreview?(bzbarsky)
Attachment #195133 - Flags: superreview+
Attachment #195133 - Flags: review?(bzbarsky)
Attachment #195133 - Flags: review+
Removed the redundant EnsureDifferentColors() and checked in to trunk at
2005-09-14 14:32 PDT.

-> FIXED
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
*** Bug 310411 has been marked as a duplicate of this bug. ***
*** Bug 312862 has been marked as a duplicate of this bug. ***
*** Bug 311726 has been marked as a duplicate of this bug. ***
Isn't it about time that this fix be incorporated into the BRANCH?
There are several bugs reporting this for the Branch but someone keeps marking them as duplicates of this one.
> Isn't it about time that this fix be incorporated into the BRANCH?

If you think it is, feel free to request branch approval on the patch and make sure to justify the reasons this is 1) needed and 2) safe for branch.

Keep in mind that not all trunk fixes will make it to branch (that's the point of a branch!), and that it's not clear why this should be one of the ones that does.
(In reply to comment #32)
> If you think it is, feel free to request branch approval on the patch and make
> sure to justify the reasons this is 1) needed and 2) safe for branch.
> 
> Keep in mind that not all trunk fixes will make it to branch (that's the point
> of a branch!), and that it's not clear why this should be one of the ones that
> does.
> 
OK. Maybe this is not the correct fix. The problem is that several people have reported this bug on the branch, and most of them are marked as a duplicate of this one. If there's an open bug for the branch for this problem, I can't find it.

Those bugs _are_ duplicates of this bug.  This is the bug for this problem.  The only way branch is involved is in deciding whether this fix should be landed on branch.
Low-risc. It's been in -current for 3 months.
Tested in a up-to-date 1.8 branch Linux build.
Attachment #205596 - Flags: approval1.8.0.1?
Comment on attachment 205596 [details] [diff] [review]
This is what was checked in (comment 27)

Please consider for 1.8.1/FF2.  1.8.0.1 is intended for major stability/security updates.
Attachment #205596 - Flags: approval1.8.0.1? → approval1.8.0.1-
Attachment #205596 - Flags: approval1.8.1?
Attachment #205596 - Flags: approval1.8.1? → branch-1.8.1?(bzbarsky)
Comment on attachment 205596 [details] [diff] [review]
This is what was checked in (comment 27)

Mats, you'll land this on 1.8.1 branch, right?
Attachment #205596 - Flags: branch-1.8.1?(bzbarsky) → branch-1.8.1+
Checked in to MOZILLA_1_8_BRANCH at 2006-01-30 17:26 PDT
Keywords: fixed1.8.1
*** Bug 337816 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: