[Webkit-unassigned] [Bug 25566] REGRESSION: bugs.webkit.org text fields are much smaller in tot

[bugzilla-daemon at webkit.org]

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


ojan at chromium.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mitz at webkit.org,
                   |                            |amanda at chromium.org




------- Comment #4 from ojan at chromium.org  2009-05-05 21:11 PDT -------
I measured the width of the "URL" input as an example. It's an input size=60
with the default font. On Windows, we match IE exactly. On mac we're now
considerably smaller, where we used to be considerably larger. There are a few
issues at play here.

1. Our computation of maxCharWidth on the mac is often ~20px smaller than the
windows value. I've filed bug 25581 for that issue.
2. Our computation of avgCharWidth is sometimes off from Windows.
3. On Mac we use floats for avgCharWidth/maxCharWidth, but the Windows APIs
return ints.
4. We use Lucida Grande as the default font on Macs and MS Shell Dlg/Monospace
as the default font on Windows. Those fonts have different metrics. That we got
the same numbers before was coincidence as best I can tell.

To give context the way we compute widths of text controls is:
input width = avgCharWidth*size + (maxCharWidth - avgCharWidth)
textarea width = avgCharWidth * cols

Here are offsetWidths for <input size=60> and <textarea cols=60> with the
default font (Lucida Grande on Mac, MS Shell Dlg / MonoSpace on Win):

Browser                     Input   Textarea
IE                                 386     503
WebKit nightly win   386     503
WebKit nightly mac  344     345
Safari 4 beta win      426     509
Safari 4 beta mac     426     441

For font-family: monospace:
Browser                     Input   Textarea
IE                                 487     503
WebKit nightly win   486     503
WebKit nightly mac  430     441
Safari 4 beta win      486     509
Safari 4 beta mac     428     443

For font-family: arial:
Browser                     Input   Textarea
IE                                 395     383
WebKit nightly win   395     383
WebKit nightly mac  315     311
Safari 4 beta win      426     449
Safari 4 beta mac     368     383

In terms of default fonts being different, I don't know what we can do about
that. In terms of getting different values for the widths, there's a number of
options. I'll let bug 25581 be for maxCharWidth and focus on avgCharWidth here.

To get the correct avgCharWidth, I tried
-getting the value out of the OS/2 table
-computing it according to
http://developer.apple.com/textfonts/TTRefMan/RM06/Chap6OS2.html
-computing it according to
http://www.microsoft.com/typography/OTSpec/os2.htm#acw
-doing all of the above and round/ceil/flooring the result

None of those gave numbers that exactly matched Windows metrics. The thing
currently checked in implements the Apple style avgCharWidth
(http://developer.apple.com/textfonts/TTRefMan/RM06/Chap6OS2.html).

So, some options moving forward:
1. Get the old metrics on the Mac by setting avgCharWidth=width('0'),
maxCharWidth=0.
2. Same as above, but use the new maxCharWidth value that we compute.
3. Try and figure out exactly how Windows computes the avgCharWidth it returns
(e.g. by generating fonts with known metrics and seeing what Windows returns).
4. Live with what we have now and just improve maxCharWidth (i.e. fix bug
25581), which would improve metrics for text inputs only.
5. Hard-code values for the 10+ fonts we care about and then fallback to one of
the above methods.

I cringe at saying this, but I lean towards option 5. It's the only way we can
match IE metrics here, short of doing option 3, which I'm skeptical can really
succeed. There are cases where the old metrics are better and cases where the
new metrics are better.


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