On Tue, Nov 26, 2019 at 11:06 PM Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> wrote: > On the long term, fontconfig should automate all the guesswork > heuristics that humans use to make sense of the pile of approximative > metadata foundries release. There’s no reason the heuristics will work > worse when automated than when done as a manual process. > > This proposal is a lot more modest. It's just streamlining the current > dumb fontconfig mode, where users provide the information needed by the > engine, without any engine smarts. > > Once this streamlining is finished it will be much clearer, where > fontconfig needs human help, and where more smarts is needed > engine-side. Sure. well, I'm not yet ready to have a detailed comment on your proposal. it was just my vision. > > > On Sun, Nov 24, 2019 at 4:30 AM Nicolas Mailhot > > <nicolas.mailhot@xxxxxxxxxxx> wrote: > >> It is presented both in traditional XML, and in YAML. > > > > I'm not keen on writing a configuration in YAML. particularly I don't > > think current features in XML can be represented in YAML to write some > > procedures and expressions. > > Raw XML is very poor to express lists and dicts of things natively. And > the new large-encoding font projects need those lists and dict in the > config (for example, good lang lists, or variable axis step > declarations). YAML is indeed simple. but, so it could prevent extending something. everything may need to be revised later. well, it may depends. but there are such risk too. also, as we use "no" for Norwegian, it always needs to be escaped to avoid misinterpreting as boolean. I don't really like it. > 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. > Pretty much all its parts. > > The proposal specifies font elements to group, with their associated > characteristics (good/bad lang, broken styles, etc). What fontconfig > does with this info can change over time. Since that is a font issue, I don't think the amount of rewriting would make a difference between the current one and the new one. implementing something in fontconfig to guess would be truly a way to reduce the cost of that. > > That‘s a departure from the current level of abstraction, where humans > directly set all the engine low-level actions. The current state has the > following consequences: > > 1. it’s not possible to reconstruct reliably, the intent behind a > configuration. That means, a CI/CD system can not deduce, the objective, > behind a config file (and therefore, check it is attained) > > 2. 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? AFAIK there was no such situations one had to rewrite the whole configurations due to some changes in fontconfig? how is it relevant to have syntax-sugars? > > Regards, > > -- > Nicolas Mailhot -- Akira TAGOH _______________________________________________ Fontconfig mailing list Fontconfig@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/fontconfig
