Apache OpenOffice (AOO) Bugzilla – Issue 16683
User default: Use system font
Last modified: 2004-08-09 15:55:57 UTC
We can get far better system integration by using the system font by default - instead of some random other 'accessible' font setting. This will make the default user experience for 99.5% of users far more pleasant at little or no a11y cost. See Philip's comments in #15507 and the patch to achieve this there [ a simple XML schema change ]
LHO->FL: Frank, please take over.
FL: We have to use the system UI font as default for OOo 2.0. Reasons for this decision are: 1. Better system integration (also important for the upcoming system widgets usage) 1.1 Windows system UI font quality is better than our own 2. It is a general Accessibility requirement. Currently the user has to manually set the option in Tools-Option-General-Accessibility tab. 3. JDS requirement to switch the user interface language on logon. This is one of our problems for asian languages, because those languages use the same areas in the font. So a Korean OOo UI font could not display Chinese. What to do: We have to activate the "Tools-Option-General-Accessibility-Use system font for user interface" by default. Furthermore we have to think about a mechanism to check, if the current system user interface font fulfills some basic requirements. If the system interface font is "bad", the Tools-Option setting mentioned above will be automatically turned off to esure a proper display of OOo 2.0. FL->FT, PL, SSA, HD: Just for clarification: I have heard from MD that S.u.s.e. delivers "bad" quality Asian fonts, because those language aren't supported officially. Is there a possibility to determine if a system UI font is "too bad" and then change back to the OOo UI font?
FT->FL: No, I do not think that there is such mechansimn and I do strongly oppose any kind of hard coded matrix that determines which Linux distribution in which language should be excepted from the new default. BTW, my wife didn't complain about Hangul (Korean) and Hanja (Chinese characters) in SuSE's (v. 8.1 and 8.2) KDE 3.1 UI.
*** Issue 15167 has been marked as a duplicate of this issue. ***
cp->fl: using the system UI font is cool stuff as the system integration is concerned. however it has some implications. for staroffice/starsuite (as opposed to openoffice): - cjk (starsuite) versions are currently able to run/display correctly even on western operating systems. this would be gone. - cde ui fonts are a nightmare in single byte locales, staroffice fonts are far better, especially for eastern european locales. - the dialogs are designed to work with staroffice ui fonts, you cannot guarantee that strings aren't cut off with the current layout management or you require increased qa effort. using the system fonts on windows is almost a no-brainer. as long as the system font can be queried from fontconfig i'm also fine with using it on unix, but forget about xlfd/fontset based system fonts. however i cannot see why this is an a11y requirement. users that rely on a11y are probably only interested in font size, not in an exact matching font shape. as well i cannot see why this is a jds requirement. we already deliver multiculti jds install sets and choose the andale sans ui font that matches the ui language. this would not change if we use a different algorithm for selecting the ui language. and please forget about checking wether the system font is good or bad. however ooo does not ship with cjk fonts so using the system fonts is as good or bad as mainting a list of candidates for ui fonts, it's like tossing a dice anyway. so this would be an issue for starsuite only.
First a comment regarding a11y and JDS: 1. Accessibility requirement definition to use system fonts: Source: http://www.section508.gov/index.cfm?FuseAction=Content&ID=12#Software [...] f) Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content, text input caret location, and text attributes. (g) Applications shall not override user selected contrast and color selections and other individual display attributes. [...] This a "shall" requirements but I also found this one as a must have requirement in an official check list for government buying agents. 2. Fine if there is not issue regarding JDS and system fonts for different languages. I propose the following regarding the issue itself: A. Always use system fonts on Windows systems B. Use system fonts only for Gnome or KDE window manager on Unix systems only Any comments?
FL->PL: The following has been discussed with CP. Enable "Tools-Option-General-Accessibility-Use system font for user interface" if system font is used. Use system fonts on A. Windows systems if desktop and OOo language are <compatible>. B. Unix systems only for Gnome or KDE window manager and if desktop and OOo language are <compatible>. Languages are <compatible> if both languages are the same or both languages are Western or both languages are East European or both languages are Asian. Which KDE or Gnome version number is needed, has to be determined by development.
.
kind of gnome integration stuff
in progress
Finally here is what was decided by CJ and SSA: - per default the system ui font will be used - a check is made whether the system ui font can display a localized string (currently made up of the standard button texts) - if this fails, the ui font as per VCL.xcu is used; the check box for usage of system ui font in tools->options is unchecked and disabled; no change to configuration is made - if the check is successful then the system font is used unless explicitly disabled in tools->options - the check box is moved from tools->options->general->accessibility to tools->options->general->view
reopen for reassign
pl->us: please verify in CWS vcl22
fixed
Verified in cws vcl22.
Need to revise 'Verified' flag.
I missed the comment from PL, what was agreed between SSA and CJ. For this complicated enhancement (this is no longer a defect; changed flag accordingly) a spec is required as well as a test case. For example the agreement does not state the intended behaviour in setup. And I currently notice a strange font used for the setup. =>Spec missing: back to UserExperience team.
As agreed this feature has to be seen in conjunction with the native widged stuff. Hence we agreed upon extending the respective spec about the enhancements made with this issue. Furthermore we agreed on handing over the font substitution *only* for the UI/desktop font to fontconfig. Background: the curent implementation does not match to a sensible UI font if the latter is set to a fontconfig defined alias as e.g. "Sans". This is actually issue 30611.
The native widget spec is now updated and covers the new UI font handling. It can be found at http://specs.openoffice.org/ui_in_general/controls/NativeWidgetRenderingSpec.sxw
reopen
please verify that the implementation in vcl22 corresponds to the spec - or was it vice versa ?
Refer to the mentioned Spec and to issue 30611 regarding the "System font" setting on fontconfig based Un*x hosts. Verified.
Verified in master workspace 680_m49.