Bug 12607 – Links with naturally italic text not repainted properly

• Component: Layout and Rendering
• Status: NEW

[Matt Lilek]

Links whose font is italic in it's normal state or whose only variant is italic are not repainted properly on hover.  Clicking one of these links and then going back in history results in the area that was not repainted  before being repainted properly, but still isn't repainted properly on hover.

This happens in Safari 2.0.4 (419.3/WebKit 418.9.1) and doesn't appear to be a regression.

The testcase I'm attaching uses "Brush Script MT" which has no "regular" style, only italic.  The font "Monotype Corsiva" also displays the same misrendering and only has regular with no italic style, but doesn't seem to be a default OS X font (probably from MS Office).

To reproduce - 
1. Open the attached test case.
2. Hover over the 'A' (note the incomplete repaint).
3. Click the link.
4. *Without moving your mouse* press backspace.
5. The 'A' should be completely red.
6. Move the mouse to unhover (no properly repainted).

[Matt Lilek]

Created attachment 12927 [details]
Testcase

[Matt Lilek]

Created attachment 12928 [details]
Screenshot of hover

[Matt Lilek]

Firefox and Opera both get this wrong too, so I don't know how fixable it even is.

See also bug 6274.

[David Kilzer (:ddkilzer)]

See also Bug 17026.

[ar]

I've just recently run into this bug with italic Helvetica at 11px.
Safari 3.1.2 (5525.20.1) & WebKit r35963.

I've found a workaround.
By adding a small equally opposing amount of padding and margin, :hover paints correctly while *seemingly* not changing the layout.

ex (longhand, using the attached "Testcase"):

a {
	padding-right: 1em;
	margin-right: -1em;
	
	padding-left: 1em;
	margin-left: -1em;
}

Notes:
- The amount of padding/negative margin depends on the font and the amount to which italicization pushes outside of the character area. In my case, with italic Helvetica, I could set the amount to 0.1em/-0.1em. In the Testcase, 1em did the trick. I guess one could use any value since it's effectively getting canceled out by the equivalent negative margin. But because there may be unforeseen side effects of this workaround, I'd think using the lowest value would be best.

- Ems are best (obviously) because they scale with increases in font size. Which means the workaround will continue to work if the user "Makes Text Bigger".

- In my case (which is wrapped in <ul> and <li>)  I also found that defining "li { list-style: none; }" causes the bug to appear. When I removed, the bug went away.

[ar]

One additional note that I should have added:
- It's the "padding-right/left" value that fixes the painting issue. The equivalent negative margin is only used to negate whatever position change the padding value made.

[Dave Hyatt]

Firefox 3 gets this right now.  They account for glyphs overflowing bounds somehow.

(In reply to comment #8)
> Firefox 3 gets this right now.  They account for glyphs overflowing bounds
> somehow.

To solve the italics case you just need to add overflow equal to the sine of the italics angle times the font height.

[Dave Hyatt]

I would have thought we only needed to do that for synthesized italics though.

Nope. We size the text box based on the glyphs' advances, which are typically the same for italics (spaces between glyphs don't change in italics) so the top edge of a the last glyph extends beyond the right edge of the text box. Of course, there are other cases where fonts draw beyond their "typographic bounds" which are harder to account for.

[Dave Hyatt]

Ah I see.  Well seems easy enough to just incorporate this as overflow.

[ar]

Created attachment 24306 [details]
Testcase 02 (negative letter spacing)

[ar]

I found that this problem also effect normal type (ex: Helvetica, non-italic) with negative letter spacing. I've attached a test case ("Testcase 02 (negative letter spacing)	"). Tested in Safari 3.1.2 (5525.20.1) & WebKit-SVN-r37469.

[Ahmad Saleem]

I am able to reproduce this bug from both test cases in Safari Technology Preview 152 and in first test case 'test case', upon hover, edges of "A" are still not completely red and have some black color and in case of other "Testcase 02", when I pressed without releasing, it changes color to "red" but red is not through "S" or "W" and has some edges as Blue.

Other browsers (Chrome Canary 107 and Firefox Nightly 107) works fine. Thanks!

[Radar WebKit Bug Importer]

<rdar://problem/99364769>