Closed
Bug 419917
Opened 17 years ago
Closed 17 years ago
Printed page contents are reflected inside bordered tables (Linux-only)
Categories
(Core :: Graphics, defect, P2)
Tracking
()
VERIFIED
FIXED
People
(Reporter: dholbert, Assigned: vlad)
References
Details
(Keywords: regression, testcase)
Attachments
(9 files)
Steps to reproduce:
1. Print testcase.
ACTUAL RESULTS:
The text is duplicated inside the table, with the lines reversed. See upcoming print-to-file results.
This doesn't happen in print-preview, so I'm guessing it's a rendering/graphics-related issue.
Bug reproduces on Linux on both FF3b3 and on latest trunk.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008022704 Minefield/3.0b4pre
Flags: blocking1.9?
Reporter | ||
Comment 1•17 years ago
|
||
Reporter | ||
Comment 2•17 years ago
|
||
Just for good measure, here's a screenshot of the PDF, for easier viewing within Firefox.
Reporter | ||
Comment 3•17 years ago
|
||
Sorry -- by "dashed area" in the testcase, I meant "on top of the table". if that's not clear.
Reporter | ||
Comment 4•17 years ago
|
||
If I remove the border from the table, or replace it with a *styled* border (as in this reference case), then the bug goes away.
Reporter | ||
Comment 5•17 years ago
|
||
Reporter | ||
Updated•17 years ago
|
Attachment #306081 -
Attachment description: testcase 1, printed to PDF (See bug here) → testcase 1, printed to PDF (BROKEN)
Reporter | ||
Comment 6•17 years ago
|
||
Ok -- as the next two testcases show, it looks like the table behaves simply as a doorway to a vertically-reflected copy of the entire page.
When printed, this testcase shows the very bottom of the page (list items 27-36) reflected in the table at the very top of the page.
Reporter | ||
Comment 7•17 years ago
|
||
Reporter | ||
Comment 8•17 years ago
|
||
This is the same as testcase 2, but now with the table at the *bottom* of the page.
Since it's at the bottom, it now shows the *top* of the page reflected upside down in it, when printed.
Reporter | ||
Comment 9•17 years ago
|
||
Reporter | ||
Updated•17 years ago
|
Summary: Text below a bordered table is duplicated inside the table, with lines reversed → Printed page contents are reflected inside bordered tables
Reporter | ||
Updated•17 years ago
|
Summary: Printed page contents are reflected inside bordered tables → Printed page contents are reflected inside bordered tables (Linux-only)
Reporter | ||
Comment 10•17 years ago
|
||
FWIW, I can't reproduce this on Mac or Windows -- pretty sure this is Linux-only.
Assignee | ||
Updated•17 years ago
|
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
Reporter | ||
Comment 11•17 years ago
|
||
Vlad: can we elevate this to P2 or P1? It causes corruption on printed documents that use bordered tables, making the contents of the tables largely unreadable (because other content is drawn on top of them). It seems pretty serious to me.
Comment 12•17 years ago
|
||
this regressed between seamonkey 2008-02-19-09-trunk and 2008-02-20-08-trunk. I don't see anything obvious in that range...
Reporter | ||
Comment 13•17 years ago
|
||
(In reply to comment #12)
> this regressed between seamonkey 2008-02-19-09-trunk and 2008-02-20-08-trunk.
> I don't see anything obvious in that range...
I'm confused by those dates you're giving for the regression range... Are you saying it regressed between February 19th and 20th, of 2008?
'cause that regression range isn't what I'm seeing here -- I can definitely reproduce the bug using a nightly from February 2nd,2008.
(build id: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008020204 Minefield/3.0b3pre)
Reporter | ||
Comment 14•17 years ago
|
||
Ok, so this has two separate regression ranges. (tested using testcase 3 aka attachment 306100 [details])
*** The first regression is between 2008-01-20 and 2008-01-21. After this change, the table no longer appears at all in printed documents.
Bonsai link:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-01-20+03%3A30%3A00&maxdate=2008-01-21+04%3A30%3A00&cvsroot=%2Fcvsroot
Bug 193001 looks like the main candidate for this first regression.
*** The second regression is between 2008-01-25 and 2008-01-26. After this change, I see the table again in a printed document, but the text is reflected in it as described in earlier comments.
Bonsai link: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-01-25+03%3A30%3A00&maxdate=2008-01-26+04%3A30%3A00&cvsroot=%2Fcvsroot
Looks like the second regression was caused by bug 413878.
Reporter | ||
Comment 15•17 years ago
|
||
(In reply to comment #14)
> Bug 193001 looks like the main candidate for this first regression.
Or possibly bug 413169, which was a cairo tweak.
Comment 16•17 years ago
|
||
> 'cause that regression range isn't what I'm seeing here -- I can definitely
> reproduce the bug using a nightly from February 2nd,2008.
OK, my testcase was actually a bit different (fieldset instead of a table), but the effect is identical. Probably the earliest regression is the real regression and the rest is the bug getting triggered in other situations.
Assignee | ||
Comment 17•17 years ago
|
||
So two things offhand... one, the text inside the table is bitmapped, this is essentially bug 416121. The other is that the inverse line ordering isn't all -that- weird. PostScript's native coordinate space is with Y increasing, so if we're somehow re-rendering things without having the right coordinate flip set up, things will appear to show up in the opposite order. (Oddly, text won't get fipped by this, it just moves the origin of the text.)
Reporter | ||
Updated•17 years ago
|
Component: Printing → GFX: Thebes
QA Contact: printing → thebes
Updated•17 years ago
|
Flags: tracking1.9+ → blocking1.9+
Priority: P3 → P2
Updated•17 years ago
|
Assignee: nobody → vladimir
Assignee | ||
Comment 18•17 years ago
|
||
I'm about to get on a flight, but could someone who has a build and can easily reproduce this apply http://tinyurl.com/2d7u2h and see if that fixes the problem? Only the first hunk needs to be applied, the changes in cairo-types-private are just there to make sure that type of problem doesn't happen again.
Comment 20•17 years ago
|
||
(In reply to comment #18)
> could someone who has a build and can easily reproduce this apply
> http://tinyurl.com/2d7u2h and see if that fixes the problem?
No, it doesn't, can still reproduce the bug with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008030214 Minefield/3.0b4pre with the patch applied.
checkout start: So 2. Mär 14:32:43 CET 2008
Comment 21•17 years ago
|
||
Curiously, the userContent.css workaround mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=416121#c5 works also for this bug. Maybe I'm wrong, but it looks like both bugs were just different symptoms of one and the same underlying issue.
I apologize for the blind guess, but can it be something similar to https://bugzilla.mozilla.org/show_bug.cgi?id=378307#c5 ??
Assignee | ||
Comment 22•17 years ago
|
||
Just committed a fix for this in upstream cairo; I'll update mozilla's cairo tomorrow. (cairo commit d89edde84de9cec9ce6f76f4f2c44dd9c1220528)
Assignee | ||
Comment 23•17 years ago
|
||
Should be fixed by the cairo update.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
Flags: in-testsuite?
Reporter | ||
Comment 25•17 years ago
|
||
Verified fixed, printing testcases 1 and 3, in
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008030604 Minefield/3.0b5pre
Thanks Vlad!
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•