Re: [Pkg-fonts-devel] Debtags localisation and font tags proposal
Just wanted to say that I fully support Nicolas's assessment. I'm not sure
what the use of those tags is if the text stack doesn't understand them. The
fontconfig+pkgkit+pango solution we developed is designed to be cross-distro
and extensible. But, oh well, who am I preaching here...
behdad
fontconfig, harfbuzz, fribidi, pango, cairo maintainer
On 05/29/2009 09:37 AM, Nicolas Mailhot wrote:
Hi,
Before Debian and Ubuntu embark on a different solution, I'd like to
point out that:
1. The "Fedora" solution is going to be the upstream
fontconfig/pango/packagekit solution, because the related code is
already merged or in the merge queue upstream
2. it is not tied to rpm, we have some minimalistic rpm glue but the
rest is freedesktop of gnome code
3. because the font package metadata is generated by fontconfig at
package creation time, it matches the font resolution mechanism
fontconfig apps (99.99% of our modern desktop) use. It is completely
useless to embark in a "better" different classification if apps will
not consume it.
4. Apart from a few specialists, no user is going to check font package
metadata manually — they'll rely on their apps to suggest the right
package to install.
5. Likewise manually-inputed tags will just bitrot over time, due to the
vast imbalance between the number of fonts to package and the number
people willing to package them.
6. package metadata has a download and processing cost, it should only
be added if it will actually be used
7. there is not reason fc-query --format '%{=pkgkit}' can not be
extended in the future once the code to make use of more info is written
(and we understand exactly what this code requires as input)
8. our font metadata syntax is font(something_fontconfig_understands)
something_fontconfig_understands uses usual fontconfig conventions (see
fc-list, fc-match and friends)
Thus, my take on the discussion on
http://lists.debian.org/debian-devel/2009/05/msg00829.html
is simply:
1. iso15924 script names in tag? Wonderful! However, pretty useless
while font-using apps do not know about iso15924. Teach apps iso15924
(which will be at fontconfig/pango level since that's where the font
substitution logic is) and it'll be trivial to make
fc-query --format '%{=pkgkit}' output it
2. add style/face information? Terrific! However current code does not
handle font family resolution yet. (it's intended to but right now
nothing consumes font(name)). So before worrying about styles, how about
making basic stupid name resolution work?
3. right now fc-query only processes font files. Ideally it should be
extended to process fontconfig xml ruleset files and the font metadata
for a package generated from the info in the font files + the fontconfig
file in the package. Trying to pass exceptions and other manually
generated info to the metadata generator otherwise won't really work —
you need to pass it to the fontconfig instance on the user system too,
and you need your packaging system and fontconfig not to have divergent
views on how to treat fonts.
Thus, to sum up, fc-query limitations are fontconfig limitations, our
apps use fontconfig, fixing fontconfig will fix apps and fc-query,
replacing fc-query instead of enhancing fontconfig will just introduce a
disjoint between apps and packages, without enhancing the user
experience, since he needs apps to process the font file and packages
anyway.