Bug 4759 – 'ex' length unit calculation (Some layout tests fail if the system primary language is Russian)

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Alexey Proskuryakov]

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:
css1/font_properties/font_size
css1/text_properties/line_height
css1/text_properties/text_indent
css1/units/length_units
fast/lists/008

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.

[Alexey Proskuryakov]

Apparently, it's [font glyphWithName:@"x"] that fails (in [WebTextRenderer xHeight]) for primary Russian. 
Many thanks to Mitz Pettel for guiding to this result!

[Alexey Proskuryakov]

  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;
}

[Eric Seidel (no email)]

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).

[Alexey Proskuryakov]

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.

[Alexey Proskuryakov]

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)

[Maciej Stachowiak]

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.

[Alexey Proskuryakov]

Landed with glyphForCharacter() being used always, not just as a fallback (discussed with Maciej on IRC).