Le jeudi 28 novembre 2019 à 14:59 +0900, Akira TAGOH a écrit :
I suppose it would be possible to define some XML elements, that contain a yaml list or dict in the text node. I don't like this kind of mixed syntax much, but that’s the only way I see to keep something XML- ish that scales humanly to the kind of list/dict we will need.
That's too bad. I don't want to mix them.
You're already doing it for
<fontvariations>AXIS1=VALUE;AXIS2=VALUE</fontvariations>
Except it's neither an XML nor a YAML list, it’s a one-of-a-kind dict format that can not be parsed natively by any off-the-shelf XML or YAML parser.
- whenever hindsight shows the low-level sequence needed to
achieve a generic goal needs tweaking, the whole configuration needs rewriting, instead of just adjusting things at the engine level.
I'm sorry, I don't get it. can you elaborate more details and specifics?
The whole locale-specific debacle for example, where you've wanted for years to try alternative approaches, and you can't because neitheir you nor other font packagers have any wish to rewrite all existing files.
That's 100% due to a bad abstraction level in fontconfig, where instead of telling the engine what locale a font file is good for (letting the engine compute the appropriate priorization strategy), users have to hardcode a specific handling strategy in their config files.
Regards,
Le jeudi 28 novembre 2019 à 08:07 +0100, Nicolas Mailhot a écrit :
- whenever hindsight shows the low-level sequence needed to
achieve a generic goal needs tweaking, the whole configuration needs rewriting, instead of just adjusting things at the engine level.
I'm sorry, I don't get it. can you elaborate more details and specifics?
The whole locale-specific debacle for example, where you've wanted for years to try alternative approaches, and you can't because neitheir you nor other font packagers have any wish to rewrite all existing files.
That's 100% due to a bad abstraction level in fontconfig, where instead of telling the engine what locale a font file is good for (letting the engine compute the appropriate priorization strategy), users have to hardcode a specific handling strategy in their config files.
Another example: during the discussion in the issue tracker you suggested using "prepend" in while discussing some legacy syntax examples. And that's not how the recommended pattern in fontpackages (that you also maintain) were written
I can tell you, none of the font packagers I know care about this kind of low-level detail. Just let us declare what other fonts are similar to a font we package. You can hash down the best way to edit fonts as a result in the engine all you want. Don't force us to decide this kind of thing. *We don't care*.
Regards,
-
Nicolas Mailhot