> 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 and replying with another address as my sil.org one seems to be silently dropped from the -devel list) 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,
Attachment:
signature.asc
Description: PGP signature
Attachment:
signature.asc
Description: OpenPGP digital signature