Apache OpenOffice (AOO) Bugzilla – Issue 16682
broken (far too small) font sizing - different from desktop & desktop settings
Last modified: 2004-04-28 14:49:49 UTC
The code in vcl/source/window/window.cxx:397 if( 1 ) { // #97047: Force all fonts except Mneu and Help to a fixed height // to avoid UI scaling due to large fonts StyleSettings aStyleSettings = rSettings.GetStyleSettings(); // #107886# allow scaling of the UI if the menu font is // slightly larger/smaller than the 8pt default int defFontheight = 8; Font aFont = aStyleSettings.GetMenuFont(); if( abs(aFont.GetHeight() - defFontheight) == 1 ) defFontheight = aFont.GetHeight(); aFont = aStyleSettings.GetAppFont(); aFont.SetHeight( defFontheight ); aStyleSettings.SetAppFont( aFont ); etc. badly screws up the work put into font size synchronization under Unix. Without that branch, it works rather well.
cp->ssa: this is actually the same as #107886#. Is there a specific reason to let the size only differ by 1 ?
cp->ssa: see also #110754#
The whole if(1) - block was introduced for accessibility reasons. We only want to have our menues using the system's font height. The dialog font size however, should be fixed to 8pt. This was to assure that dialogs will not exceed the screen size - which typically occured when switching to some HighContrast color scheme on Windows (which also increases font sizes a lot). Now, our korean friends had a problem with the 8pt size of their UI font which is not readable very well at this size. Thus, we allow a setting of 9pt as well, if the system says so. On korean Windows the UI font is actually set to 9pt. In my eyes the -1 check is the problematic hack here - we should be more tolerant and allow for a slightly bigger range to better reflect the system's font sizes. But being too tolerant will definitely lead to dialogs not fitting on screen anymore. Another change I'd like to make is to set the minimum size to 9pt when running with a korean UI. This would allow for a readable korean UI on non-korean locales. Michael, what font size is your desktop reporting ?
these ibis frontend makes me climbing up the wall
reassign NOT resolve
So all my desktops are better than 1400x1050 at ~100dpi. At that size an 8point font is eye-strainingly difficult to read. Thus I configure my system to use a 12 point font - which works nicely for everything except OO.o - where the text is unreadable. If there is a problem on windows - such that the font sizes are mangled badly; it'd be nice not to cripple Unix systems where it's sensible to have higher font sizes :-) can the font size not be clobbered in the app. Also - it seems profoundly inaccessible to me to have 1 font size which is what the (visually impaired) user selected for Menus - and then expect him/her to be able to read substantially smaller 8point font in all dialogs, buttons, combo boxes etc. - that's surely just daft. Clearly - if the user selects a gargantuan font size, then the app will become unusable - but surely, that's always going to be the case - cropping it IMHO creates a worse problem than it solves. Obviously going forward - a toolkit with layout can do a lot better job of ensuring the dialogs are nicely packed and far smaller - that's the right long-term solution IMHO. Thanks.
So we should check the screen resolution as well to find a font size that guarantees on-screen dialogs.
If you insist on adding such 'nanny' code - then can you ensure it is easy to disable - perhaps an environment variable or somesuch - so we don't have to patch this out of our OO.o on an ongoing basis. Thanks.
To make sure that no dialog exceeds the screen size, the UI font will be allowed to grow by the ratio between the user's desktop size and the desktop size that was used when designing the dialogs, ie 800x600. In the case of a 1400x1050 desktop, that would allow for a UI font size of 14pt.
*** Issue 20895 has been marked as a duplicate of this issue. ***
Fixed in CWS vcl17. See also #i21238#.
ss->ru: please verify in CWS vcl17.
.