Bug 25581 - maxCharWidth computation in SimpleFontDataMac.mm is smaller than Windows results
Summary: maxCharWidth computation in SimpleFontDataMac.mm is smaller than Windows results
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-05 18:09 PDT by Ojan Vafai
Modified: 2010-02-12 19:24 PST (History)
4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ojan Vafai 2009-05-05 18:09:59 PDT 
The numbers we get on the mac are often 10-20px smaller than the numbers we get on Windows. This matters because it is one of the factors that makes our text inputs smaller than IE on Mac WebKit. 

Currently we grab the maximumAdvancement off the NSFont. On Chromium Linux (which gets the same values as Windows for Windows fonts), we compute the maxCharWidth as the xMax-xMin of the font by looking at the hmtx font table. Or something like that. :) Amanda is working on a patch that tries to do the same on the Mac.