Apache OpenOffice (AOO) Bugzilla – Issue 78983
use language of OO.o instead of working locale of Finder
Last modified: 2008-09-19 11:48:29 UTC
OOo aqua - ja language build - m217 - aquavcl01 when changing the system preferences "International - Language" from English to Japanese, it is necessary also to restart the Finder (Force Quit) before launching OOo, then the characters display correctly. Taken from issue 78322: ------ Additional comments from ekato Sun Jun 17 05:28:35 +0000 2007 ------- @sparcmoz: Thanks for the confirmation. I think we should use a language of OO.o instead of working locale of Finder. I mean to use kFontJapaneseScript instead of smSystemScript for GetThemeFont() when the package is built for ja, and so on. @hdu: Is there any way (API) to get the package's built language?
ekato: what target please? is this a feature or a defect?
IMHO, it is not a defect but a feature request. Actually I'm not sure this is good idea or not. Maybe we should implement using fallback fonts first. "Using Font Fallback Objects" with ATSUI may help (http://developer.apple.com/documentation/Carbon/Conceptual/ATSUI_Concepts/atsui_chap6/chapter_6_section_2.html) .
Changing OOo's language setting makes much more than just setting the default fonts, though they make the most visible difference of course. Even with faked font fallbacks Office would behave different than after a restart. The proper solution is either 1. to send a language change event and make all language setting users listen to this and handle them 2. force quit and silently restart office I'm afraid the first alternative is quite expensive, because identifying and fixing all direct and indirect users of the language setting is not easy. It would e.g. involve to send and handle a "default font changed" event, etc.
Changing OOo's language setting makes much more than just setting the default fonts, though they make the most visible difference of course. Even with faked font fallbacks Office would behave differently than after a restart. The proper solution is either 1. to send a language change event and make all language setting users listen to this and handle them 2. force quit and silently restart office I'm afraid the first alternative is quite expensive, because identifying and fixing all direct and indirect users of the language setting is not easy. It would e.g. involve to send and handle a "default font changed" event, etc.
*** Issue 79746 has been marked as a duplicate of this issue. ***
Created attachment 46932 [details] test patch to show Arabic ui fonts in Arabic OOo Aqua package
Created attachment 46933 [details] screenshot with Arabic UI fonts
In issue 79746, I've add a comment about using UI languages of OOo to get default system fonts, and marked that as duplicate of this issue. @ hdu: What do you think about using a table to map between OOo UI languages and ATSUI font scripts?
ekato: now my dialogs are working too - similar as your screenshot - but I have not applied your test patch.
I found this useful page about Mac OSX and Arabic. http://www.smi.uib.no/ksv/ArabHome.html I wrote the author and asked him to comment on Maho m221 build. He provided some comments from a well informed user perspective that I think may be useful. I will attach. Please excuse the fact that some of the issues have been fixed already!!
Created attachment 46934 [details] user Comments
It seems this problem is more difficult than my first thought. There seems some more related problems. And I noticed my screenshot (arabic.png) was not the result of the "ui locale" patch but actually its from my glyph fallback patch in issue #79676. Sorry for the confusion. Here is the summary at the moment. 1. GetThemeFont() with smSystemScript might not return appropriate font when Mac OS X's system language preference doesn't match a language of OOo. 1'. To solve this, I propose using a mapping table between OOo's UI language and script language of ATS. 2. However, GetThemeFont() with smSystemScript and/or with kFontArabicScript never returns Arabic font name. It always returns "Lucida Grande", which don't contain Arabic glyphs. So 1' doesn't work for all languages. 2'. It may be solved with wrapping GetThemeFont() and return appropriate system font like "Geeza Pro" for Arabic script. 3. But for Arabic case, since "UI_SANS" for "ar" locale seems to be assigned as "Tahoma; Traditional Arabic;..." in VCL.xcu, "Geeze Pro" won't be used even patch 2' is applied. In this case, Tahoma is used and it shows squares because it doesn't contain Arabic glyphs. 3'. Adding "Geeze Pro" before Tahoma in VCL.xcu will force to use the Arabic fonts. However, since it doesn't contain Latin glyphs, some UI strings written in English becomes squares... So it requires a glyph fallback as in issue #79676. So we need, 1) improve Aqua specific default UI font selection mechanism for every locales 2) implement proper glyph fallback mechanism (issue #79676) @ hdu: Could I ask one question? Related problem 3. I couldn't understand why "Tahoma" is used even I modified the code around GetThemeFonts() force to use "Geeza Pro" for Arabic script? On Japansese OOo package, the font selected by GetThemeFonts() is always used instead of fonts listed in VCL.xcu. Which code should I look into knowing about VCL.xcu font replacement?
mapping table and wrapper for GetThemeFont() is now implemented in aquavcl02 This should fix the problem with ja package with English System language. The remaining thing will be done in other issues * implement proper glyph fallback (issue #79676) * improve VCL.xcu related things (for Arabic)
This issue started at issue 78322. The problem there was the First Start Wizard (and later dialogs) displayed squares when a ja build was launched with System Preferences - Language set to English. The workaround was to change System Preferences to ja, and restart (Force Quit) Finder. Now with aquavcl02 the workaround is not required - using salframe.cxx 1.48.242.10 - see attached screenshot. The problem is still there for Arabic. If I understand correctly this is the expected result. Therefore I will mark this issue as "verified" .
Created attachment 47177 [details] launch build-ja with System-en
sparcmoz: Thanks for the verification. For the Arabic problem I've filed a new one in #80163.
reopening. See mailing list - this brought cs UI to unusably slow letters.
small fonts are fixed now in aquavcl02. sparcmoz: can you please verify the original issue again?
reset target
Confirmed cs is too small with 1.48.242.10 salframe.cxx The patch is 1.48.242.11 salframe.cxx Verified by testing vi,cs,en-US,ja With System Preferences - International = English First Start Wizard and Tools-Options dialog. All look reasonable size.
Verified patch in 1.48.242.11 salframe.cxx and behaviour as expected.
Closing verified issue.