Re: RFC font ui

Hi Rob,

Robert Staudinger wrote:
>
> On 2/1/07, Reinout van Schouwen <reinout@gmail.com> wrote:
>>
>> Hi Tomas,
>>
>> 2007/1/28, Tomas Frydrych <tf@o-hand.com>:
>>
>> > I have been pondering couple of issues that relate to our font UI that
>> > as user I am not happy with, and think should be addressed before the
>> > 2.6 release.
>>
>> (...)
>>
>> I recently bumped into an article about font selection UI and thought
>> it might be relevant in this discussion.
>>
>> Read it here: http://unifont.org/fontdialog/
>
> Hi Reinout,
>
> thanks for pointing that out. I'm not convinced about the proposed
> approach though, so here is my backseat HCI person, "orange sunglasses
> wannabe" verdict:
> + Excessive categorisation and hierarchy is bad. Only a small fraction
> of the "tree" will be of interest for one user, few are going to mix
> e.g. arabic and cjk (estimation).
> + Using standard widgets in a nonstandard way (tree view in combo box)
> is counter intuitive.
> + Advanced information such as ttf/ps font and similar may be needed
> for a graphics app but hardly for a word processor.
> + Trying to render previews inline in the combo is a cpu / disk hog.
> Been there.

Agreed entirely.

> Probably sorting the last recently used fonts on top of the font combo
> would go a long way. We'll possibly have that for 2.6.

Yes, that would be really nice if you have the time.

> Even better if
> it's prefilled with used fonts detected at document load time (would
> be some more work).

Would be even nicer. We would need some XP API for this at the
PD_Document/FV_View level, but neither of these classes deals directly
with fonts; I suppose the fl_DocLayout::findFont() could track what
fonts are being requested in some kind of a vector/stack container. If
this XP api was used for updating the combobox, it would mean that the
list would reflect both when the users choses a font from the combo and
from the dialog.

Tomas
Received on Fri Feb 2 09:13:54 2007