On Wed, Oct 17, 2018 at 10:03 PM Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> wrote: > You seem to be thinking about generating current fontconfig syntax from > templates in rpm macros. I definitively don't want to go there in Fedora > font packages. Such generators are quite brittle and hell to > debug/maintain. They're sort of ok for third party tools that try to > coax fontconfig on doing things, they're not ok as distro core > infrastructure. If you want to generate from rpm macros, you need to > define something that can be generated simply (and current fontconfig > syntax is not that). How is it that hell to debug/maintain? if you look at the outcome, that should be obvious and what I'm planning to do isn't more than what we currently do by the hand. just thought integrating it into fontpackages' rpm macro because most of fonts packages uses it but sometimes missing config files. indeed fontconfig eventually should detect generic families without any explicit rules and that is a long standing issue for me though. > If we agree on some form of simplified syntax, sufficient for the needs > of the average font packager, I want the result to be read by fontconfig > natively without intermediary generation. Even if it's in an > experimental config namespace only activated on Fedora, that we agree > can be dropped later if the experiment fails. I'm not sure how current recipes can be simplified though. if there are any useful sugar forms, I'm willing to add it into fontconfig if that helps something. > > > For individuals, majority requirements should be satisfied by a tool > > such as fonts-tweak-tool. for system-wide and complicated scenarios, > > we need a handy way to get things done. for Fedora specific thing, I > > eventually want to integrate this into rpm macro and prepare an > > environment to have config files without any knowledge or minimal. > > that would helps a lot for packagers. > > Well I wrote down what I though minimal knowledge could be: identifying > the generic (that's definitely something a human can do better than > fontconfig), listing down font families that the font family can serve > as substitute for/can be substituted with (fontconfig can not have any > opinion on fonts families not present on system) and listing down all > the font family name variations that should be merged, if fontconfig is > not smart enough to identify them itself. Sure. well, I meant about syntax-wise for fontconfig config. > The merging part is hugely important from a usability POW, because the > OFL has created a situation where forks lead to renames, and because > font designers suck at font naming. Right. > They will rename every possible variation of their fonts so they can > wash their hands on metric compatibility, or just for marketing purposes > (acmefont new better), or to enable subsetting, or to sell a pro > version, but the average user is not going the have every possible font > variation on his system. > > So it's much better to present all the variations on acmefont as a > single acmefont font family, and have fontconfig manage internally those > variants, than have fontconfig fallback to an unrelated font, because > the original document didn't use the same variant as the current system. > These days displaying all acmefont family names in selectors is about as > useful as displaying the font version embedded in the font files. Sure > it allows disambiguation. But who except the original font designer > cares about this? If you have the exact match on-system for one of the > font other names, by all means have fontconfig return data from this > file, but don't force users to do the untangling manually. They don't > care enough to do it. They will just (rightly) say fontconfig font > selection sucks. Sure. that should be improved but sounds like another topic or in the later milestones for this idea so far. but yes, definitely. Anyway, thanks for feedbacks! > > -- > Nicolas Mailhot -- Akira TAGOH _______________________________________________ fonts mailing list -- fonts@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to fonts-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/fonts@xxxxxxxxxxxxxxxxxxxxxxx
