294733 - incorrectly sized line-box for :first-letter pseudo-element

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[philippe (part-time)]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050518 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050518 Firefox/1.0+

This is a spin of from Bug  290125.
Comments from that bug apply here.

When using the :first-letter pseudo-element, the line-box for the first letter
is sized inconsistently depending on the text content that follows it. The
line-box is also sized differently than on Firefox Win XP.

Attachment 183902 [details] for bug  290125, and its screenshot (comparing Win XP vs Mac
OS X) is illustrative of this.

1/ It doesn't matter whether the first-letter is floated (drop-cap) or not.
2/ Using plain ascii text, the line-box for the first-letter does not shrink to
the size of the letter (behaviour I would expect based on what happens on Win
XP, and the comments in bug 290125). 
3/ When inserting numerical entities, the line-box for the first letter is
shrinked to the size of the letter. But if a <span> (doesn't matter if it  is a
<a>, <em>, <strong>, <cite>,... ) preceeds the numerical entity, the line-box
for the first-letter is not sized the same way. The same problem happens if I
insert non-roman text (test case containing Japanese text).

Attachment 183902 [details] for bug  290125 uses a floated first-letter. I'll attach a
test case with a non floated first-letter.

Note that these difference only happen with Gecko 1.8 (tested with Firefox
1.0+). Firefox 1.04 doesn't show these differences.

Reproducible: Always

Comment 1

[philippe (part-time)]

Attachment: Test case A: with num.entities

comparing the line-box with or without numerical entities (&#8217 used here).
red border: no entities; grey border: with entities; blue border: entities
after a <span>

Comment 2

[philippe (part-time)]

Attachment: screenshot for test case A

Comment 3

[philippe (part-time)]

Attachment: test case B: with Japanese text

Comment 4

[philippe (part-time)]

Attachment: screenshot for test case B

Comment 5

[philippe (part-time)]

Regression range: between 2004-11-16 and 2004-11-17, which leads (possibly) to bug 21616.

Comment 6

[philippe (part-time)]

Most of the comments above are outdated (applied only to Fx 1.5). 
The bug is still very much alive on Minefield trunk (OS X),as it doesn't apply the part of CSS 2.1 that says:

# In order to achieve traditional drop caps formatting, user agents may
# approximate font sizes, for example to align baselines. Also, the glyph
# outline may be taken into account when formatting.

http://www.w3.org/TR/CSS21/selector.html#first-letter

Comment 7

[philippe (part-time)]

Attachment: updated test case

Comment 8

[philippe (part-time)]

Attachment: screenshot of updated test case

Minefield OS X on the left; Firefox 2.0.0.3 Win XP on the right

Comment 9

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Is GetBoundingMetrics, or its replacement in the new thebes world (has it even been replaced yet?), not properly implemented on the Mac?  (It was originally for MathML, so it wouldn't surprise me if it wasn't.)

Comment 10

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

Attachment: right approach?

roc, is this the right approach?  This makes the testcase work for me -- i'll attach an additional testcase that exercises a bit more stuff, though I don't have one that exercises the complex glyphs bit.

Comment 11

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

This is cross-platform; it just never worked right on the mac under 1.8, but win32 etc. have the same problem with the trunk.  The patch doesn't have the win32 and linux code, but it should be easy; I just want to make sure that roc agrees with this approach before I do the win32/linux work.

Comment 12

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

You didn't need any changes in gfx/src/thebes/nsThebesFontMetrics to call GetGlyphMetrics from GetBoundingMetrics?

Comment 13

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

Nope, the only thing that calls GetBoundingMetrics any more is a few MathML frames, and only because they haven't been rewritten yet.  I actually had some code that added NS_WARNING("Nothing should be calling me!")'s to GetBoundingMetrics just to make sure that nothing's calling it, but it isn't really necessary.

The first-letter stuff is handled by the new thebes textframe, where it requests a tight bounding box for the glyphs that are part of the first letter frame; however, there wasn't any code that did anything special for a request for tight bounding metrics.

I forgot to attach my additional testcase, but it's basically the one here, except with the text-transform property removed, and the first letter replaced with something with a descender like "y" and another with ".o" (because in the latter case, both the ".o" end up in the first letter box... not sure that's a bug, but it's a good test of calculating tight bounds of multiple glyphs).

Comment 14

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

(er, if someone tries to compile the patch, you'll need to change GetGlyphMetrics to GetGlyphBounds in gfxQuartzFontCache.h)

Comment 15

[philippe (part-time)]

Ooh. :-) !

This works pretty well on OS X 10.4.10 ppc. Nice.
All my test cases display correctly, including using combinations of ::first-letter and ::first-line. Didn't find any problem so far.
At one point I had a hang when using font-family:'Times', with first-line+first-letter - I doubt that is from this patch, there are other reports of these (like bug 388049). And I couldn't reproduce it.

Comment 16

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

argh, I wish I'd been CCed on this bug.

I have a generic patch for glyph bounds computation in bug 96041 (actually I have a slightly more up to date version locally). That patch should fix this (for Mac) along with all the bugs in normal text display. If you want to help me finish that for Linux and Windows you'd be most welcome ...

Comment 17

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

So I think we should just focus on that. Sorry about the extra work

Comment 18

[philippe (part-time)]

This now works perfectly fine, fixed by bug 96041.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a9pre) Gecko/2007092404 Minefield/3.0a9pre

THANKS Roc !