408182 - Random width of printed borders of table with border-collapse

Status: RESOLVED FIXED

(Core :: Layout, defect, P3)

Description

[Andreas Lange]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2007121204 Minefield/3.0b3pre

Printing a table with border-collapse gives unexpected results. Will attach testcase and image.

Print in Fx2 lost one cellborder but all others are there and have the same width. 

Print in 3.0b3pre loses several borders and the others are of several different widths. Much worse in current Fx3 than Fx2 that is.

Comment 1

[Andreas Lange]

Attachment: Medium testcase

Pretty random table which exhibits several problems.

Comment 2

[Andreas Lange]

Attachment: Screenshot of first testcase, Fx3 vs OSX preview

Comment 3

[philippe (part-time)]

dupe of bug 407031 ?

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

yeah probably, but this bug makes it clearer there's a regression.

Comment 5

[Andreas Lange]

I get more or less the same preview with a nightly from 2007-04-01. 2007-01-01 refuses preview and prints on paper with more borders but some variation in thickness, while a 2007-02-16 build crashes on print. 

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Here's what happens here --- actually in the testcase https://bugzilla.mozilla.org/attachment.cgi?id=291725, drawing the top horizontal line:
-- nsCSSRendering's DrawSolidBorderSegment tries to fill a rectangle (0,120,6120,60). That's 1 CSS pixel high.
-- nsThebesRenderingContext is at 80 appunits per CSS pixel. I guess this is because PDF is 72dpi. The gfxRect r is therefore (0,1.5,76.5,0.75).
-- gfxContext::Rectangle snaps to device pixels and gets (42,44,77,0). Poof, nothing is going to be drawn.

Either UserToDevicePixelSnapped should be a no-op for certain kinds of surfaces, or we should give those surfaces 1 appunit per dev pixel (5760dpi) and scale everything down by a factor of 80, and do something about font rasterization :-(

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

I must say I'm not a big fan of this GetFlags API, or the operator hack it's been used for, but it does the job here.

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 295333 [details] [diff] [review]
fix

I agree, but then again, this is exactly the type of thing that it works well for, hacky as it may be...

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in