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@sugarlabs.org wrote:
From: Tomeu Vizoso tomeu@sugarlabs.org Subject: Re: F11 for XO1 - Fonts To: "Daniel Drake" dsd@laptop.org Cc: "Yioryos Asprobounitis" mavrothal@yahoo.com, fedora-olpc-list@redhat.com, "sugar-devel" sugar-devel@lists.sugarlabs.org Date: Tuesday, August 4, 2009, 7:15 AM On Tue, Aug 4, 2009 at 10:48, Daniel Drakedsd@laptop.org wrote:
2009/8/4 Tomeu Vizoso tomeu@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