Closed
Bug 90434
Opened 23 years ago
Closed 19 years ago
[FIX] printing selected text leaves dark background
Categories
(Core :: Printing: Output, defect, P2)
Core
Printing: Output
Tracking
()
RESOLVED
FIXED
People
(Reporter: mail-mozilla.org, Assigned: MatsPalmgren_bugz)
References
()
Details
(Keywords: fixed1.8.1, testcase)
Attachments
(7 files)
351 bytes,
text/html
|
Details | |
350 bytes,
text/html
|
Details | |
80.29 KB,
image/png
|
Details | |
120 bytes,
text/html
|
Details | |
160.48 KB,
image/jpeg
|
Details | |
1.08 KB,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
1.78 KB,
patch
|
bzbarsky
:
approval-branch-1.8.1+
mtschrep
:
approval1.8.0.1-
|
Details | Diff | Splinter Review |
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'.
Comment 1•23 years ago
|
||
Comment 2•23 years ago
|
||
Comment 3•23 years ago
|
||
Comment 4•23 years ago
|
||
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
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.9
Comment 6•23 years ago
|
||
Very strange, the align=justify is what does it in a table.
Updated•23 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.1
Updated•22 years ago
|
Priority: -- → P2
Target Milestone: mozilla1.1 → Future
Comment 7•21 years ago
|
||
*** Bug 219281 has been marked as a duplicate of this bug. ***
Comment 8•21 years ago
|
||
*** Bug 158759 has been marked as a duplicate of this bug. ***
Comment 9•21 years ago
|
||
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
Comment 10•21 years ago
|
||
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.
Comment 11•21 years ago
|
||
*** Bug 232289 has been marked as a duplicate of this bug. ***
Comment 12•20 years ago
|
||
*** Bug 239755 has been marked as a duplicate of this bug. ***
Comment 13•20 years ago
|
||
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)
Updated•20 years ago
|
Assignee: rods → core.printing
Status: ASSIGNED → NEW
QA Contact: sujay
Comment 14•20 years ago
|
||
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.
Comment 15•20 years ago
|
||
*** Bug 255852 has been marked as a duplicate of this bug. ***
Comment 16•19 years ago
|
||
*** Bug 263026 has been marked as a duplicate of this bug. ***
Comment 17•19 years ago
|
||
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.
Comment 18•19 years ago
|
||
NOT for "print range= selection".
Comment 19•19 years ago
|
||
*** Bug 286681 has been marked as a duplicate of this bug. ***
Comment 20•19 years ago
|
||
*** Bug 293435 has been marked as a duplicate of this bug. ***
Comment 21•19 years ago
|
||
*** Bug 297474 has been marked as a duplicate of this bug. ***
Comment 22•19 years ago
|
||
*** Bug 298586 has been marked as a duplicate of this bug. ***
Comment 23•19 years ago
|
||
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 | ||
Updated•19 years ago
|
Assignee: printing → mats.palmgren
Summary: printing selected text leaves dark background → [FIX] printing selected text leaves dark background
Target Milestone: Future → ---
Assignee | ||
Comment 24•19 years ago
|
||
Attachment #195133 -
Flags: superreview?(bzbarsky)
Attachment #195133 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 25•19 years ago
|
||
Also, why do PaintUnicodeText() need EnsureDifferentColors() and not the other two? Shouldn't that be the responsibility of GetSelectionColors()? PaintUnicodeText: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsTextFrame.cpp&rev=1.520&root=/cvsroot&mark=2676-2683#2661 PaintTextSlowly: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsTextFrame.cpp&rev=1.520&root=/cvsroot&mark=3384-3390#3365 PaintAsciiText: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsTextFrame.cpp&rev=1.520&root=/cvsroot&mark=3641-3647#3613
Comment 26•19 years ago
|
||
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+
Assignee | ||
Comment 27•19 years ago
|
||
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
Comment 28•19 years ago
|
||
*** Bug 310411 has been marked as a duplicate of this bug. ***
Comment 29•19 years ago
|
||
*** Bug 312862 has been marked as a duplicate of this bug. ***
Comment 30•19 years ago
|
||
*** Bug 311726 has been marked as a duplicate of this bug. ***
Comment 31•19 years ago
|
||
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.
Comment 32•19 years ago
|
||
> 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.
Comment 33•19 years ago
|
||
(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.
Comment 34•19 years ago
|
||
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.
Assignee | ||
Comment 35•19 years ago
|
||
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 36•19 years ago
|
||
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-
Assignee | ||
Updated•19 years ago
|
Attachment #205596 -
Flags: approval1.8.1?
Updated•18 years ago
|
Attachment #205596 -
Flags: approval1.8.1? → branch-1.8.1?(bzbarsky)
Comment 37•18 years ago
|
||
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+
Assignee | ||
Comment 38•18 years ago
|
||
Checked in to MOZILLA_1_8_BRANCH at 2006-01-30 17:26 PDT
Keywords: fixed1.8.1
Comment 39•18 years ago
|
||
*** 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.
Description
•