[Pkg-fonts-devel] Debtags localisation and font tags proposal

[Behdad Esfahbod]

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.
>