[Webkit-unassigned] [Bug 16768] Position and thickness of underline as text size changes

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Oct 6 17:46:23 PDT 2009


https://bugs.webkit.org/show_bug.cgi?id=16768





--- Comment #33 from mitz at webkit.org  2009-10-06 17:46:22 PDT ---
Further comments:

1. How do you ensure that underlines are accounted for in repainting? If you
use -underlinePosition or its equivalent, is there a guarantee that the
underline will not go below the descender? It it does (and you don’t change
that behavior; I think the AppKit behavior is to keep it within the descender),
then you should add it to visual overflow.

2. This runs the width iterator an extra time on every underlined text run at
paint time. It would be better to avoid that, because I think it may impact
performance. Perhaps following a model similar to Font::floatWidth()’s
fallbackFonts parameter (and utilizing the existing logic in all code paths
that support it) would be better. Then you could just have one place that goes
over the list of fonts used in the text run, instead of iterating over the
entire glyph buffer.

3. I have mentioned that AppKit behavior on Mac OS X a few times. The reason is
that AppKit text views are used alongside WebViews on Mac OS X, and it would be
good to have consistency between the two. It would be unfortunate to change
WebKit to match AppKit “in spirit” without getting the details right.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list