Bug 4759 - 'ex' length unit calculation (Some layout tests fail if the system primary language is Russian)
Summary: 'ex' length unit calculation (Some layout tests fail if the system primary la...
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P3 Normal
Assignee: Alexey Proskuryakov
Keywords: HasReduction
Depends on:
Reported: 2005-08-30 11:59 PDT by Alexey Proskuryakov
Modified: 2006-01-09 02:11 PST (History)
1 user (show)

See Also:

proposed patch (1.19 KB, patch)
2006-01-08 07:38 PST, Alexey Proskuryakov
mjs: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Proskuryakov 2005-08-30 11:59:19 PDT
Steps to reproduce:

1. Set the system primary lnguage to Russian (in International control panel); re-login
2. Run layout tests

Results: five of them fail:

Discussion: all these tests use lengths specified in ex units. Apparently, these are calculated incorrectly 
in some cases. I have traced this up to CSSPrimitiveValueImpl::computeLengthFloat(), which gives 
different results for different primary languages.

For example, length_units.html uses ex values for two font sizes, with factor values of 7.66406 and 
19.1602 (primary English). However, with primary Russian these become 7 and 18.
Comment 1 Alexey Proskuryakov 2005-08-30 13:10:48 PDT
Apparently, it's [font glyphWithName:@"x"] that fails (in [WebTextRenderer xHeight]) for primary Russian. 
Many thanks to Mitz Pettel for guiding to this result!
Comment 2 Alexey Proskuryakov 2005-08-30 22:23:29 PDT
  Interestingly, the following reduced test fails for English primary language, too (also, see the thread at 
<http://www.cocoabuilder.com/archive/message/cocoa/2005/6/1/137649>). There's something in 
WebKit that makes fontWithName work, at least for some languages...

int main (int argc, const char * argv[]) 
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    NSFont *font = [NSFont fontWithName:@"Times-Roman" size:12];
    NSLog(@"Font: %@", [font description]);
    NSGlyph xGlyph = [font glyphWithName:@"x"];
    NSLog(@"x glyph: %d", xGlyph);
    [pool release];
    return 0;
Comment 3 Eric Seidel (no email) 2005-12-28 01:17:49 PST
I would encourage alexey or mitz to take a stab at a patch here, as most of us don't live on a non-english 
system day-to-day.  Wonderful reduction, btw.  It would be even better if we could create a layout test to 
show this (that would not require any specific system language setting).
Comment 4 Alexey Proskuryakov 2005-12-28 04:19:35 PST
I approached this several times, but couldn't find a solution. Other ways of measuring width or 
advancement give different results, and I don't see any other way to find a glyph (other than the failing 
glyphWithName). I'm not a Cocoa expert, though.

Judging from comments and cvs log, this is a pretty sensitive area, so the results for Roman systems 
should probably be preserved exactly.
Comment 5 Alexey Proskuryakov 2006-01-08 07:38:26 PST
Created attachment 5544 [details]
proposed patch

Fallback to glyphForCharacter() if -[NSFont glyphWithName] has failed.

(Sorry for a not quite canonical form of the patch, the repository is
inaccessible at the moment)
Comment 6 Maciej Stachowiak 2006-01-09 01:57:58 PST
Comment on attachment 5544 [details]
proposed patch

you could coneider using only the new way to get the x glyph, if it works for
all languages.
Comment 7 Alexey Proskuryakov 2006-01-09 02:11:58 PST
Landed with glyphForCharacter() being used always, not just as a fallback (discussed with Maciej on IRC).