I'm sorry to intervene... but would it be possible the XO specific requirements (eg
font size 7, removal of Xft.dpi etc) to be taken care by the iso to nand script?
So Sugarlabs builds as wide as possible and hardware specific things are managed by the
installation scripts? or a post install config script?
Showing properly in a variety of hardware is not only a matter of font size but also
toolbar sizes, images etc I do not know if SL should undertake a sophisticated scaling at
this point.
my 2c
--- On Tue, 8/4/09, Tomeu Vizoso <tomeu(a)sugarlabs.org> wrote:
From: Tomeu Vizoso <tomeu(a)sugarlabs.org>
Subject: Re: F11 for XO1 - Fonts
To: "Daniel Drake" <dsd(a)laptop.org>
Cc: "Yioryos Asprobounitis" <mavrothal(a)yahoo.com>,
fedora-olpc-list(a)redhat.com, "sugar-devel"
<sugar-devel(a)lists.sugarlabs.org>
Date: Tuesday, August 4, 2009, 7:15 AM
On Tue, Aug 4, 2009 at 10:48, Daniel
Drake<dsd(a)laptop.org>
wrote:
> 2009/8/4 Tomeu Vizoso <tomeu(a)sugarlabs.org>:
>>> A method to specify the font size (measured in
points).
>>
>> What font size would be that?
>
> That would be up to the deployments.
> For example, OLPC would choose 7.
I meant to ask to which UI elements this font size would
apply to.
>> I guess we should, for improved accessibility. And
would be convenient
>> if the paddings, line widths, icon sizes, etc also
scaled accordingly
>> (may not be possible with current gtk+).
>
> Not yet, but there are ongoing efforts to create an
overall "scale
> factor"-like system that will be nice.
>
>> I don't hate it in itself. But I need to know
better why using Xft.dpi
>> is not a good solution (real technical
disadvantages) and which
>> mechanism uses gtk+/gnome so we can reuse their
work there.
>
> It's going against an established system that ensures
that fonts of
> the same point size are the same physical dimensions
when shown on
> different screens and on paper.
>
> To me it also just doesn't make sense... if the fonts
are too small,
> then the logical thing is to use bigger fonts, not to
start pretending
> that you have a screen with different characteristics
from the one
> that you are using. This would also be important to
deployments where
> technical resources are lesser - at least to me,
thinking of font size
> in terms of the size of the font (a familiar concept
to MS word
> users!) is much more logical than thinking about the
number of pixels
> in a square inch on the display on which the fonts
will be rendered.
> (for example, for someone unfamiliar with that line of
thinking, it is
> not obvious whether you should increase or decrease
the DPI in order
> to make the fonts bigger)
>
> Freetype visually optimizes the font renderings based
on the DPI and
> sometimes gives odd-looking results when the selected
DPI is not that
> of the actual display. (ever seen the subpixel
rendering option result
> in worse appearance than before? this is usually the
cause)
>
> It also will confuse any applications that make
calculations based on
> the DPI of the fonts against the millimetre-width of
the screen --
> although these are not that common.
>
> GNOME use this same kind of approach. GNOME ships
default font sizes
> and has an "Appearance" dialog with a fonts tab that
lets you increase
> or decrease the font size. KDE is similar.
That's all ok, but how do you see us moving from using
Xft.dpi (that
today can get us font sizes that look good on several
systems), to
font sizes to achieve the same?
Regards,
Tomeu