From nicolas.mailhot at laposte.net Fri May 29 13:37:37 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 29 May 2009 15:37:37 +0200 Subject: [Pkg-fonts-devel] Debtags localisation and font tags proposal In-Reply-To: <4A1FC404.6010603@canonical.com> Message-ID: <1243604257.13732.54.camel@arekh.okg> 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. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From behdad at behdad.org Fri May 29 14:23:02 2009 From: behdad at behdad.org (Behdad Esfahbod) Date: Fri, 29 May 2009 10:23:02 -0400 Subject: [Pkg-fonts-devel] Debtags localisation and font tags proposal In-Reply-To: <1243604257.13732.54.camel@arekh.okg> References: <1243604257.13732.54.camel@arekh.okg> Message-ID: <4A1FEFC6.8070900@behdad.org> 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. >