fontconfig config priority

Nicolas Mailhot nicolas.mailhot at laposte.net
Tue Dec 22 23:14:26 UTC 2009


Le jeudi 17 décembre 2009 à 23:06 +0900, Akira TAGOH a écrit :
> Hi,

Hi,

> I have a question and a suggestion for the fontconfig
> config priority in the font packaging policy.
> 
> I'm writing a small script to validate the fontconfig config
> in packages to not mess up.

Wondeful! If you want commit access to fontpackages to have it
integrated with our other tools, just ask (if the licensing is OK with
you)

> the goal is to check if the
> priority is set accurately and the config files are
> following our templates. it roughly started working. but I'm
> not quite sure what "Latin" in LGC really covers. is it
> similar to what Latin-[1-10] covers? or more strictly
> applied?

LGC roughtly means latin-like alphabetical scripts that are written
linearly with few ligatures, and those that exist optional (not indic,
not arabic, not cjk…) Also an unofficial requirement for those scripts
is to be from regions where people are familiar enough with latin
letters not to butcher them when they include them in fonts

A more professional description would be welcome :)

> The suggestion is, about improving the policy to set the
> priority more strictly. I have two ideas:
> 
>  1) have variety of the priorities for non-LGC fonts as well
>  like for default, main and low perhaps.
>  even though LGC fonts has a priority for default font,
>  but not for non-LGC fonts. it may messes up their default
>  font if multiple fonts with the same priority such as 65
>  are installed. this priority things could avoids this issue.
>  it may be something like:
> 
>  65-69 ... High priority non-LGC fonts
>  70    ... Main non-LGC font list
>  71-64 ... Low priority non-LGC fonts

Those ranges are inherited from the fontconfig master file split that
occured a few years ago upstream. I'm not so sure that nowadays they are
the most appropriate. We've certainly started pushing a lot more
fontconfig files that upstream thought at the time, and are hitting many
limitations (layout that was supposed to be flexible enough to allow
customization, but is not really because of the files that have kept
long font lists). If you try to split the non-latin file, for example,
you quickly hit prefix starvation. However, that's just MHO. Other
people may not share it. But please keep an open mind and do propose
another file naming convention if you find a better one. I think that
the main requirements would be to

1. clearly define the ranges a local sysadmin, a distro, and fontconfig
upstream fallbacks should use
2. try to separate classes of fonts to minimize risks of conflicts (like
the current lgc/non lgc split)
3. make locale appear when it is relevant
4. make the font names appear in filenames so people do not need
grepping to locate where the rules associated with their font are

It is possible in fontconfig to use something longer that the current
2-digit prefixes to order files

>  2) describes what exactly "default", "Main" and "Low"
>  priority means.
>  during developing and testing this script, I see some
>  packages is possibly wrongly set the priority to their
>  fontconfig config files, for example, some font is set the
>  priority to 57 that is supposed to be the default font, but
>  not marked as mandatory in comps. so I'd suggest to update
>  comps or change the priority like:
> 
>  - mandatory for higher priority
>  - default for main priority
>  - optional for low priority
> 
>  and update the policy with it as well.

I don't think using comps brutally will work :

1. currently we do not have separate comps groups for every
fontconfig/css generic, fontconfig and apps really want a separate font
stack for each generic (though this could be fixed by splitting the
master fonts comps group)

2. sometimes our requirements are a lot more subtle than
mandatory/default : dejavu and liberation are both default, but their
ordering is not random

However I can only applaud trying to improve our fontconfig packaging,
and writing qa tests: this is sorely needed, if we want to continue
improving Fedora font support.

Best regards,

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/fonts/attachments/20091223/dfd7f6d8/attachment.bin 


More information about the fonts mailing list