Behavioral changes to KFontChooser

[James Richard Tyrer]

Chusslove Illich wrote:
> (I wanted to make few tweaks to make it more translatable, but couldn't just
> skim past the other issues, and it suckered me in...)
> 
> I consider the behavior of KFontChooser and KFontRequester at present to
> have some usability problems. On top of that, there are crash situations:
> e.g. in KCM Fonts, use "Set all fonts" to pick a font which doesn't have
> bold style, then choose on "Window title" font (which is bold by default) --
> crash.
> 
> The main usability issue I had is that the family/style/size combination in
> KFontChooser need not at all times reflect an available combination, and the
> preview shows something at random (e.g. when an arbitrary size is entered in
> the size spinbox for non-vector font). And similarly, it is possible to
> select a non-existing combo in that manner (e.g. the "Set all fonts" example
> above).
> 
> The proposed fixes with the following patch (unfortunatelly longish):
> 
> http://caslav.gmxhome.de/misc/kdelibs-kdeui-fonts-2007-12-09.diff
> 
> * Make sure that an unavailable combination cannot be chosen by user or set
>   by setFont methods. Make sure that the font attribute widgets at any
>   moment contain only an available combination of family/style/size. Make
>   sure these widgets are in perfect sync, and with the sample text.
> 
> * "Smart" browsing through families: the style and size that user explicitly
>   selected are kept and always first tried when the family is switched, else
>   a near match. E.g. user selects style bold, then switches to a family
>   which doesn't have bold and the style reverts to regular, the switches to
>   a family which has bold and the style is again shown as bold (and same for
>   the size). This is for the use case of "I want a 10pt bold, let's see
>   what's there."
> 
> * The style listbox double checks available styles (try set/get style and
>   see if they match before showing it). Still renames Normal into Regular,
>   but no longer renames Oblique into Italic (but considers them as fallback
>   for each other when switching between families).
> 
> * The size listbox/spinbox operates in two modes here. When the font is
>   vector, size can be chosen arbitrary in the spinbox, but make sure it's
>   also displayed in the listbox; e.g. when moving from 28 (one of offered
>   sizes) to 29 (not offered), insert 29 into listbox, modify this item as
>   the user spins on to 30, 31, and remove it once 32 is reached (another
>   offered size). When the font is bitmap, spinbox clicks move to next
>   available size, not +-1; when an arbitrary value is entered, it gets
>   rounded away to neareast available size.
> 
> * The sample text. No longer a QLineEdit, but a QTextEdit with vertical
>   centering. So that the text wraps, shows scrollbar eventually, and the
>   translators can enter multiline samples, e.g. a verse (someone inquired
>   about it few months back on kde-i18n-doc). The SampleEdit widget in the
>   patch does this; it has a side effect of showing window background color
>   around centered text, instead of the text background, that I don't know
>   how to remove (but looks kind of neat to me anyway):
>   http://caslav.gmxhome.de/image/kde4-font-chooser-sampleedit-01.png
> 
> * The KFontRequester checks the font given to it, and modifies it to a near
>   available match, rather then accepting as is and letting label show
>   something not there. E.g. in the "Set all fonts" example above, when the
>   font with no bold style is picked the "Window title" font will revert to
>   regular.
> 
> This is my first involved take on GUI code (only pushing text around so
> far), so don't restrain from corrective scolding.
> 

I tried your patch and it appears to compile, but it doesn't work 100%

Note that it appears to attempt to fix at least one regression vs. KDE3. 
  It now shows only the available sizes for bitmapped fonts.

I find one issue that need to be fixed which is the point size for 
bitmapped fonts.

First, it isn't working.  The formula is:

	PointSize = PixelSize(72/ScreenDPI)

and the code appears to have it backwards somewhere.  I am unable to 
determine if this is your patch or not since I can't find the integer 
"72" anywhere. :-(

This leads to a related problem that the preview isn't correct.  Try the 
font "Newspaper" which comes with X.org and has only one size 32 Pixels. 
  With my system's DPI of 100 it is shown as 44 pt. rather than 27 pt. 
Note that KDE3 had this +/- correct.

Second is the related issue of whether the point sizes should be 
integers.  I don't think so although 1 decimal place is sufficient. 
Exactly what is needed and/or will work correctly depends on how Qt 
handles bitmapped fonts.  It will resize bitmapped fonts which may 
either be a problem or a feature.  How does it decide if it will use the 
pixel size which is the closest to the requested size or if it will 
resize the font.  The method which should work in any case (but might 
not) is to use float for the point sizes of bitmapped fonts (or all 
fonts if this is easier) and only display 1-1/2 decimal place (note that 
a half decimal place can only display '0' or '5').

To illustrate the second issue, look at the font "Fixed[Sony]" which 
also comes with X.org.  This has three sizes 16, 17, & 24 pixels. 
However at 100 DPI, I only have 2 choices: 12 & 17.  You might think 
that 16 pixels -> 11.50 points is rounded up and that 17 pixels -> 12.25 
points is rounded down.  However, forcing 96 DPI (KCM Appearance & 
Themes -> Fonts) which should fix the problem since 16 pixels -> 12 
points exactly and 17 pixels -> 12.75 points (exact fraction) SHOULD 
round up to 13 _but_it_doesn't_.  So, something is screwed.  It appears 
that KDE-3/Qt-3 chooses the 16 pixel fonts in both cases.

-- 
JRT