Apparently the metrics structure in Thebes was updated some time ago with a few new members. gfxPangoFonts now uses plenty of heuristics to get better display. We should look through these for OS/2.
As I just posted to the newsgroup, it seems that one should use the x-advance property instead of the glyph width for all horizontal metrics. That's how one should change the computation of the aveCharWidth property. I also wonder, if we should round the emHeight of all fonts to a integer number of pixels. That is what apparently happens on the other platforms. That might then also influence the problem reported in bug 439195.
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
I have worked myself through the GetMetrics used in gfxPangoFonts now and some of the tricks used there are nice, but I don't want to take all of it because it's pretty convoluted (sometimes without obvious reasons). The emHeight-integer trick does _not_ help the chrome font issue of bug 439195, though. That's because 9pt always scale to integer pixels anyway (either 9.*96./72.=12.00 or 9.*120./72.=15.00).
Created attachment 395927 [details] test DLL This is the DLL for testing, meant to be used together with the still-current nightly at <http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/contrib/2009/08/2009-08-09-03-comm-1.9.1/>. As one can see, even if using the broken Workplace Sans v0.4 created with TypeTool v3 that Alex posted some time ago, the entry fields in the prefs now get a useful size.
Didn't see any problems on my system, heard no complaints, so I pushed this: http://hg.mozilla.org/mozilla-central/rev/f11ffc7eaeff http://hg.mozilla.org/releases/mozilla-1.9.2/rev/bc28ac5281e4 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/4470654d36cb (It doesn't help with the 96dpi problem, though.)
No longer blocks: 439195
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
status1.9.1: --- → .4-fixed
Resolution: --- → FIXED
status1.9.2: --- → beta1-fixed
You need to log in before you can comment on or make changes to this bug.