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

[bugzilla-daemon at webkit.org]

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





--- Comment #37 from Yusuke Sato <yusukes at chromium.org>  2009-10-07 06:19:07 PDT ---
mitz, thanks for the review!

I've modified the get_underline_metrics_mac_impl patch as follows:

- Stopped using CoreText APIs. Replaced them with NSFont calls.
- Removed the #ifdefs for Tiger.
- Fixed styles following your comment.


For the calc_underline_metrics_for_a_textrun patch, I did the following:

> 1. How do you ensure that underlines are accounted for in repainting?

Added a few lines of code which keeps the underline within the descender.

> 2. This runs the width iterator an extra time on every underlined text run at ...

Modified Font::underlineMetricsForSimpleText(). Now the function scans a run
only once. Thanks! 

Please take another look.


> Should this apply to other text decorations? AppKit scales up strikethrough lines as well.

I agree that it'd be better to apply this kind of change to strike-through
lines, but I'd like to finish the underline issue first.

>  In particular I don’t think AppKit derives the underline position from the font’s -underlinePosition.
...
> 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.

So you're saying that just using NSFont methods is not perfect, right? If so,
could you let me know if there is a document/code/... of AppKit which I could
use as a reference to emulate the AppKit's behavior?
(Sorry if it's a silly question. I'm not so familiar with Mac programming...)

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