Bug 12607 - Links with naturally italic text not repainted properly
Summary: Links with naturally italic text not repainted properly
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 418.x
Hardware: Mac OS X 10.4
: P3 Normal
Assignee: Nobody
URL:
Keywords: HasReduction, InRadar
Depends on:
Blocks:
 
Reported: 2007-02-04 20:51 PST by Matt Lilek
Modified: 2022-08-30 20:17 PDT (History)
10 users (show)

See Also:


Attachments
Testcase (213 bytes, text/html)
2007-02-04 20:52 PST, Matt Lilek
no flags Details
Screenshot of hover (3.18 KB, image/png)
2007-02-04 20:53 PST, Matt Lilek
no flags Details
Testcase 02 (negative letter spacing) (523 bytes, text/html)
2008-10-12 12:11 PDT, ar
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Lilek 2007-02-04 20:51:51 PST
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).
Comment 1 Matt Lilek 2007-02-04 20:52:53 PST
Created attachment 12927 [details]
Testcase
Comment 2 Matt Lilek 2007-02-04 20:53:33 PST
Created attachment 12928 [details]
Screenshot of hover
Comment 3 Matt Lilek 2007-02-04 20:58:01 PST
Firefox and Opera both get this wrong too, so I don't know how fixable it even is.
Comment 4 mitz 2007-02-04 22:37:55 PST
See also bug 6274.
Comment 5 David Kilzer (:ddkilzer) 2008-02-20 08:20:13 PST
See also Bug 17026.

Comment 6 ar 2008-08-28 13:33:59 PDT
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.
Comment 7 ar 2008-08-28 13:52:50 PDT
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.
Comment 8 Dave Hyatt 2008-08-28 14:15:55 PDT
Firefox 3 gets this right now.  They account for glyphs overflowing bounds somehow.

Comment 9 mitz 2008-08-28 14:38:34 PDT
(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.
Comment 10 Dave Hyatt 2008-08-28 14:46:50 PDT
I would have thought we only needed to do that for synthesized italics though.

Comment 11 mitz 2008-08-28 14:55:52 PDT
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.
Comment 12 Dave Hyatt 2008-08-28 15:41:33 PDT
Ah I see.  Well seems easy enough to just incorporate this as overflow.
Comment 13 ar 2008-10-12 12:11:20 PDT
Created attachment 24306 [details]
Testcase 02 (negative letter spacing)
Comment 14 ar 2008-10-12 12:12:41 PDT
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.
Comment 15 Ahmad Saleem 2022-08-30 15:43:38 PDT
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!
Comment 16 Radar WebKit Bug Importer 2022-08-30 20:17:30 PDT
<rdar://problem/99364769>