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.