handling of fonts in the langpack plugin

[Bill Nottingham]

With the introduction of the langpack plugin for yum, we've managed to
remove most of the manually-maintained group metadata for i18n/l10n.
However, one spot we still have a problem is for fonts.

We *could* for any language that's requested, do an install of
font(:lang=<whatever>), but that doesn't give us a useful mechanism to
prioritize the proper default font.

Would it be worth it for the default fonts for a particular locale to
Provide: default-font(lang=<foo>)? Maintaining this could be problematic,
but we would only need to do this for locales that aren't handled by dejavu
or similar latin/greek/etc. fonts.

Bill

Fw: Re: handling of fonts in the langpack plugin

[Nicolas Mailhot]

------------------------------ Message original ------------------------------
Objet:    Fwd: handling of fonts in the langpack plugin
De:       "Behdad Esfahbod" <behdad.esfahbod(a)gmail.com&gt;
Date:     Ven 24 février 2012 22:35
------------------------------------------------------------------------------

So, if i understand it correctly, you're asking for a way to get the
default font for a language. Right?

That sure sounds like something Fontconfig shall be able to answer,
but it's tricky. Do you need this on the server or client?  Cause
FcMatch and friends only return fonts that are installed. What you
want can be done by processing the ":lang=foo" pattern by Fc
Sybstitute calls, then taking the resulting family list and pickin the
first one that supports the lang in question.

After you answer my question re which side you need this on I can
hopefully provide more concrete advice.

Cheers,

behdad

PS. Boy, I miss Fedora people.

-- 
Nicolas Mailhot

[Nicolas Mailhot]

Le Ven 24 février 2012 21:01, Bill Nottingham a écrit :

>  Would it be worth it for the default fonts for a particular locale
> to
>  Provide: default-font(lang=<foo>)? Maintaining this could be problematic,
>  but we would only need to do this for locales that aren't handled by dejavu
>  or similar latin/greek/etc. fonts. 
The main problem I see is that current provides are fully automated, and only
require looking at the font package being created content. What you ask for is
a cross-repo require, so either people would need to fill them in manually
(with the reliability and cruft accumulation of cross-processes) or each font
package would need to depend on every other font package in the repo at build
time to check if it's the priority one for a specific language or not.

(you need all the font packages in the repo since they all install font config
snippets, and especially for the langs you're thinking of those snippets will
play priority override games)

Both are not specially appealing

-- 
Nicolas Mailhot

[Bill Nottingham]

Nicolas Mailhot (nicolas.mailhot(a)laposte.net) said: 
>  The main problem I see is that current provides are fully automated,
> and only
>  require looking at the font package being created content. What you ask for is
>  a cross-repo require, so either people would need to fill them in manually
>  (with the reliability and cruft accumulation of cross-processes) or each font
>  package would need to depend on every other font package in the repo at build
>  time to check if it's the priority one for a specific language or not. 
How so? I'm wondering about the feasibility of a hardcoded list. Right now,
we 'know' which fonts should be the default for non-dejavu languages (at
least, we set them up that way in comps), so why not add a quick hardcoded
provide for those 10-20 packages and just change that provide if the
preferred font infrequently changes?

Sure, it's ugly and manual, but it's a limited level of manual work that
shouldn't explode.

Bill

[Behdad Esfahbod]

On 02/27/2012 11:41 AM, Bill Nottingham wrote:
>  Nicolas Mailhot (nicolas.mailhot(a)laposte.net) said: 
> > The main problem I see is that current provides are fully automated, and only
> > require looking at the font package being created content. What you ask for is
> > a cross-repo require, so either people would need to fill them in manually
> > (with the reliability and cruft accumulation of cross-processes) or each font
> > package would need to depend on every other font package in the repo at build
> > time to check if it's the priority one for a specific language or not.
>  
>  How so? I'm wondering about the feasibility of a hardcoded list. Right now,
>  we 'know' which fonts should be the default for non-dejavu languages (at
>  least, we set them up that way in comps), so why not add a quick hardcoded
>  provide for those 10-20 packages and just change that provide if the
>  preferred font infrequently changes? 
So, right now we Provide "font(:lang=fa)" from all fonts supporting that
language.  Why can't you create a metapackage default-fonts that provides
"font(default:lang=fa)", etc that would then require the default font for the
language?

Moreover, that metapackage can be made automatically.  It just needs to
install all font packages available in the repository, walk through all
languages, and see what font fontconfig chooses for that language.

behdad


>  Sure, it's ugly and manual, but it's a limited level of
> manual work that
>  shouldn't explode.
>  
>  Bill
>  _______________________________________________
>  fonts mailing list
>  fonts(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/fonts
>  http://fonts.fedoraproject.org/

[Bill Nottingham]

Behdad Esfahbod (behdad(a)behdad.org) said: 
>  On 02/27/2012 11:41 AM, Bill Nottingham wrote:
>  > Nicolas Mailhot (nicolas.mailhot(a)laposte.net) said: 
>  >> The main problem I see is that current provides are fully automated, and only
>  >> require looking at the font package being created content. What you ask for is
>  >> a cross-repo require, so either people would need to fill them in manually
>  >> (with the reliability and cruft accumulation of cross-processes) or each font
>  >> package would need to depend on every other font package in the repo at build
>  >> time to check if it's the priority one for a specific language or not.
>  > 
>  > How so? I'm wondering about the feasibility of a hardcoded list. Right now,
>  > we 'know' which fonts should be the default for non-dejavu languages (at
>  > least, we set them up that way in comps), so why not add a quick hardcoded
>  > provide for those 10-20 packages and just change that provide if the
>  > preferred font infrequently changes?
>  
>  So, right now we Provide "font(:lang=fa)" from all fonts supporting that
>  language.  Why can't you create a metapackage default-fonts that provides
>  "font(default:lang=fa)", etc that would then require the default font for the
>  language? 
The installation of the default fonts for all supported languages (for
some suitable definition of all) is not really my concern - we have a
'fonts' group for that; we could do what you suggest there, but it's not the
primary usage case.

What I'm concerned with is someone who's installing in Japanese, or wants to
specifically add Japanese support, and wants to pull *just* the default
Japanese fonts - a single metapackage doesn't help here.

Bill

[Behdad Esfahbod]

On 03/06/2012 12:57 PM, Bill Nottingham wrote:
>  Behdad Esfahbod (behdad(a)behdad.org) said: 
> > On 02/27/2012 11:41 AM, Bill Nottingham wrote:
> >> Nicolas Mailhot (nicolas.mailhot(a)laposte.net) said: 
> >>> The main problem I see is that current provides are fully automated, and
> only
> >>> require looking at the font package being created content. What you ask for
> is
> >>> a cross-repo require, so either people would need to fill them in manually
> >>> (with the reliability and cruft accumulation of cross-processes) or each
> font
> >>> package would need to depend on every other font package in the repo at
> build
> >>> time to check if it's the priority one for a specific language or not.
> >>
> >> How so? I'm wondering about the feasibility of a hardcoded list. Right now,
> >> we 'know' which fonts should be the default for non-dejavu languages (at
> >> least, we set them up that way in comps), so why not add a quick hardcoded
> >> provide for those 10-20 packages and just change that provide if the
> >> preferred font infrequently changes?
> >
> > So, right now we Provide "font(:lang=fa)" from all fonts supporting that
> > language.  Why can't you create a metapackage default-fonts that provides
> > "font(default:lang=fa)", etc that would then require the default font for
> the
> > language?
>  
>  The installation of the default fonts for all supported languages (for
>  some suitable definition of all) is not really my concern - we have a
>  'fonts' group for that; we could do what you suggest there, but it's not the
>  primary usage case.
>  
>  What I'm concerned with is someone who's installing in Japanese, or wants to
>  specifically add Japanese support, and wants to pull *just* the default
>  Japanese fonts - a single metapackage doesn't help here. 
Err.  Right.  Then one meta source package providing multiple packages, one
for each language.  Or better, one for each font package.  Ie. one meta
package that would require dejavu-fonts and provide "font(default:lang=xx)"
for all the languages that dejavu-fonts is the default font package for...

behdad

>  Bill
>

[Akira TAGOH]

I suppose we can do similar thing what I did on
http://tagoh.fedorapeople.org/fonts/fedora-current-defaultfonts.html.
It was completely machine-generated from what the packages provides in the fontconfig
config files (+ comps to pick up the languages we support and to notice if it's
intentional result or not, but anyway).

I guess the plugin could reasonably works in a timely manner if we can provides
font(:priority=<n>) and font(:targetlang=<foo>) when the locale-specific
overrides rule is applied.

----- 元のメッセージ -----
| With the introduction of the langpack plugin for yum, we've managed
| to
| remove most of the manually-maintained group metadata for i18n/l10n.
| However, one spot we still have a problem is for fonts.
| 
| We *could* for any language that's requested, do an install of
| font(:lang=<whatever>), but that doesn't give us a useful mechanism
| to
| prioritize the proper default font.
| 
| Would it be worth it for the default fonts for a particular locale to
| Provide: default-font(lang=<foo>)? Maintaining this could be
| problematic,
| but we would only need to do this for locales that aren't handled by
| dejavu
| or similar latin/greek/etc. fonts.
| 
| Bill
| _______________________________________________
| fonts mailing list
| fonts(a)lists.fedoraproject.org
| https://admin.fedoraproject.org/mailman/listinfo/fonts
| http://fonts.fedoraproject.org/

[Nicolas Mailhot]

Le Lun 27 février 2012 03:12, Akira TAGOH a écrit :

Hi,

>  I suppose we can do similar thing what I did on
>  http://tagoh.fedorapeople.org/fonts/fedora-current-defaultfonts.html.
>  It was completely machine-generated from what the packages provides in the
>  fontconfig config files (+ comps to pick up the languages we support and to
>  notice if it's intentional result or not, but anyway).
>
>  I guess the plugin could reasonably works in a timely manner if we can
>  provides font(:priority=<n>) and font(:targetlang=<foo>) when the
>  locale-specific overrides rule is applied. 
This won't work at rpm level because you need to export tuples
(name,langage,priority) and rpm only understands monovalued properties

(ideally we should also export the family variant not only its name)

We sort of worked around the (name,language) tuple barrier by requiring a
package to only contain a single font family but for priority that can not
work.

You may try to hack around with font(:lang) = version but that requires some
serious thought to map fontconfig priorities to rpm versions (and what will
happen at upgrade time when a font is promoted/demoted)?

This is all a PITA that would be way more natural and less error-prone if
someone taught rpm to work with tuple properties. Because that's what fonts
metadata really requires

Regards,

-- 
Nicolas Mailhot

[Akira TAGOH]

> >>>> On Mon, 27 Feb 2012 11:28:26 +0100,
> >>>> "NM" == "Nicolas Mailhot"
> <nicolas.mailhot(a)laposte.net&gt; wrote: 
NM> This won't work at rpm level because you need to export tuples
NM> (name,langage,priority) and rpm only understands monovalued properties

No need to limit trying to find out the way for rpm only
because we are talking about the langpack plugin right?
We could have another metadata to make it easy if it's
really useful. anyway, the most important thing can be
provided by Provides: fonts-<alias>-<lang> =
<priority>. that should contains the enough information. if
we set the higher version for the higher priority package
like 1000 - the numeral prefix in the config file, rpm would
automatically address the better fonts against the version I
suppose?

NM> You may try to hack around with font(:lang) = version but that requires some
NM> serious thought to map fontconfig priorities to rpm versions (and what will
NM> happen at upgrade time when a font is promoted/demoted)?

me neither. guess the real version in the package would
ensure for upgrading? dunno. or recommend to do yum
distro-sync or even update might work? ;)

NM> This is all a PITA that would be way more natural and less error-prone if
NM> someone taught rpm to work with tuple properties. Because that's what fonts
NM> metadata really requires

NM> Regards,

NM> --
NM> Nicolas Mailhot

--
Akira TAGOH

[Nicolas Mailhot]

Le Lun 27 février 2012 13:04, Akira TAGOH a écrit :
> >>>>> On Mon, 27 Feb 2012 11:28:26 +0100,
> >>>>> "NM" == "Nicolas Mailhot"
> <nicolas.mailhot(a)laposte.net&gt; wrote:
>
>  NM> This won't work at rpm level because you need to export tuples
>  NM> (name,langage,priority) and rpm only understands monovalued properties
>
>  No need to limit trying to find out the way for rpm only
>  because we are talking about the langpack plugin right? 
If you don't define rpm-friendly metadata, repoquery, yum and rpm won't work
on your new keys (and I predict it'll be a major testing/QA/audit problem if
the only testing app is anaconda) and you'll need to ship yum/rpm metadata
anyway (so users can actually select packages), bloating indexes and slowing
down yum.

So I would advise against it.

Also such a change requires cooperation of all font packagers, ie guidelines
and FPC approval, so be careful not to spend too much time on a solution that
can't be sold there.

Regards,

-- 
Nicolas Mailhot