Bug 4759

Summary: 'ex' length unit calculation (Some layout tests fail if the system primary language is Russian)
Product: WebKit Reporter: Alexey Proskuryakov <ap>
Component: Layout and RenderingAssignee: Alexey Proskuryakov <ap>
Status: RESOLVED FIXED    
Severity: Normal CC: mitz
Priority: P3 Keywords: HasReduction
Version: 420+   
Hardware: Mac   
OS: OS X 10.4   
Attachments:
Description Flags
proposed patch mjs: review+

Alexey Proskuryakov
Reported 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: 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.
Attachments
proposed patch (1.19 KB, patch)
2006-01-08 07:38 PST, Alexey Proskuryakov
mjs: review+
Alexey Proskuryakov
Comment 1 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!
Alexey Proskuryakov
Comment 2 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; }
Eric Seidel (no email)
Comment 3 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).
Alexey Proskuryakov
Comment 4 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.
Alexey Proskuryakov
Comment 5 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)
Maciej Stachowiak
Comment 6 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.
Alexey Proskuryakov
Comment 7 2006-01-09 02:11:58 PST
Landed with glyphForCharacter() being used always, not just as a fallback (discussed with Maciej on IRC).
Note You need to log in before you can comment on or make changes to this bug.