[Pkg-fonts-devel] [i18n] Input Method and Fonts improvements for Gutsy

Mon Aug 6 21:26:27 UTC 2007

> Dear all,
> 
> I have taken a first look at the current font and input method situation
> in Gutsy (Tribe 3 Live CD and up to date installation on HDD) and have a
> few suggestions to make.

[...]

> 3. Fonts:
>  a) language selector:
> The idea with the language selector handling the fontconfig
> configuration is nice, however, it needs some tweaking:
>  * more languages: I will add more config files for more locales; needs
> some testing and probably some community feedback.
>  * Question: how to handle those config files which come with the font
> packages? Font preference handling should be done by language selector,
> while font specific options can remain the the config files installed by
> the font packages? If that's the case, we need to check all the font
> packages and tweak those where it's not the case.
> 
>  b) Font packages:
> I see a problem: space on the Live CD is a bit "restricted"... but some
> font packages come with multiple fonts inside and install them all, even
> if we don't need them. This wastes precious space.
> I'm still trying to get an overview about which fonts cover which
> Unicode ranges and which fonts should be taken into account for the
> three Alias fonts "sans-serif", "serif" and "monospace".
> Bottom line: Some font packages come with fonts we don't need for this
> purpose. Question: how to handle this?

Hi Arne and fellow Ubunteros,

(cc-ing to the Debian Fonts Task Force)

I agree that the tradeoff between space-saving and better font support
out of the box is tricky and that we need to tackle this sooner than later.

What is needed is one solid quality open implementation of a script per
language-pack shipped by default in the liveCD. Locales which are
covered by various fonts should be studied closely to reduce the default
desktop seed to a good quality minimal set. IOW how many stylistic
variants do we need per writing sytem? IMHO "decorative fonts" (as in
offering more variety beyond having a working writing system
implementation) can get installed via apt-get/synaptic after the install.

Ideally this core selection on the liveCD would be similar to the common
open font set currently being defined at the freedesktop.org level:
http://www.freedesktop.org/wiki/Software/Fonts

For example if we have Dejavu, do we still need Vera?
Should we not demote some Pan-unicode fonts like Freefonts when we have
other open fonts with better quality for certain blocks? (Gentium,
Charis SIL, or the Magenta or GFS fonts?)

AFAICT some font packages include too many variations by default
(ttf-arabeyes would be one possible example to investigate).

IMHO some serious re-shuffling of a few fonts packages needs to happen.

I suggest we re-use/contribute to the work done by the Debian Fonts Task
Force to make this review easier and quicker:

- debreview: an archive-wide review script for fonts (with previews and
full metadata for each font per package)
http://pkg-fonts.alioth.debian.org/review

- ttfcoverage (or we could use fontforge): a libfont-ttf-perl-based
script to determine precise per script/block of a font.

These scripts (available in the pkg-fonts team svn) could probably be
improved but they are a good start I think. The plan on the Debian side
is to have the review script run regurlarly on the whole Unstable
archive. We should do the same for the Ubuntu archive.

Btw, many more open fonts have been released over the past few months
with the growth of the open font movement and packaging work for this is
ongoing. There are various syncs underway to get these font packages
from Debian upstream into Ubuntu.

I'm going to set up a bzr branch to host the work done on the pkg-fonts
svn hosted on Alioth (http://svn.debian.org/wsvn/pkg-fonts/) where an
increasing number of font package maintainers are collaborating. So the
LP fonts team can track what is happening and the Debian/Ubuntu
ecosystem can improve the overall font landscape:
https://launchpad.net/people/fonts

Maybe now would be a good time to launch a ongoing poll throughout the
LoCos and the i18n communities for their preferred open font and then
based on that judge by freeness/quality/coverage which fonts are most
appropriate:
https://blueprints.launchpad.net/ubuntu/+spec/better-fonts-as-default-using-polls

> Option 1: We craft a seperate package, just for the Live CD and put
> selected fonts from the other font packages together, just for this
> single purpose.
> Caveat: might conflict with the other font packages (duplicate fonts
> files), should probably not be used on the default installation on the
> users' harddisks.
> 
> Option 2: We split the font packages into 2: a "base" package with the
> fonts we need for the Live CD and an "extra" package, where the rest of
> the fonts are in.
> Caveat: it's not always easy to draw the line which font should be in
> base and which ones in extra. Users might get confused.
> 
> I would probably prefer option 1... less work, if we can restrict it to
> the Live CD only.

I also like the idea of a core-open-fonts package. But we need to be
prepared to change it often according to the (sometime conflicting
needs) of the various language communities.
We should probably set up clear criteria from the start.

And we need to suggest font packaging best practises with these
requirements in mind: freeness/quality/coverage.

Or should it simply be a metapackage pulling in optimized fonts packages
linked to the language-packs?

[...]

>  b) CJK fonts:
> This topic really is... erm... difficult.
> For the Arphic fonts (and probably also a Heiti (sans-serif, like DejaVu
> Sans) and Yuanti (rounded, like Kochi Gothic) font) I have the following
> in mind:
> The problem is, that many characters share the same codepoint in
> Unicode, but have a different shape (number of strokes and stroke order)
> in the different CJK regions (China, Hong Kong / Macao, Taiwan, Japan,
> Korea). This is one of the main reasons why users in these regions
> prefer different fonts.
> My approach would be to put all character shape variants into a single
> TTC (TrueType Collection) and use a different glyph ID to Unicode
> codepoint mapping for each "virtual font".
> Instead of having 5 separate TTF files, each about 25MB in size, we
> would end up with only one TTC file (about 30 MB in size), which
> produces 5 "virtual fonts". Saves a lot of space. ;)

A very elegant approach :)

In the same vein, we may also consider asking upstream font
designers/project maintainers to reduce the duplication of Unicode
blocks sometimes found in certain fonts and let fontconfig work its magic.

> (If you need more details about this technology, I can elaborate about
> it in a follow up mail)
> 
> Caveat: QT3 does not support TTC fonts. GTK2 however has no problem with
> it. QT4 >= 4.3 is also able to use them.
> So, I basically wait until KDE4 is released and adopted into Ubuntu.
> Otherwise KDE users can't use the TTC fonts.

Yes and with font review and packaging there are the interactions with
the rest of the writing systems components that we need to improve.
Having a better default selection is good but a smarter font menu and a
font manager are also needed.

> That's it for the moment, if you have some opinion about one of these
> issues, please speak up. :)

Let's work on this :)

I'd like to throw in a few links about efforts in this area for others
in the community to look into and contribute:

An earlier thread started by mdz a while ago and in which many including
Denis Jacquerye (Dejavu Lead) pointed out some of the challenges and
proposed solutions:
https://lists.ubuntu.com/archives/ubuntu-devel/2007-May/023642.html

The TextLayout summits:
http://www.freedesktop.org/wiki/TextLayout

The Open Fonts in Debian BoF:
https://penta.debconf.org/~joerg/events/67.en.html

An Ubuntu spec on open-fonts:
https://blueprints.launchpad.net/ubuntu/+spec/open-fonts

Lots of good challenging stuff ahead...

> Cheers
> Arne

Cheers,

-- 
Nicolas Spalinger
http://scripts.sil.org
http://pkg-fonts.alioth.debian.org
https://launchpad.net/people/fonts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-fonts-devel/attachments/20070806/2e2fbc49/attachment.pgp 