Fontconfig language update proposal
Hi all,
CONTEXT
I've now spent several years redoing font packaging automation in
Fedora, culminating with this guideline change proposal:
https://pagure.io/packaging-committee/pull-request/934
It should soon be dead easy to package industrial quantities of nice
OFL fonts Fedora-side, without giving up on quality, right?
Unfortunately, no. Font files have gotten a lot more complex in the
past decade. But font authors are no more careful than they were in the
past. Thus, the amount of fixing required fontconfig-side has grown.
However, the fontconfig language is little more expressive today, than
it was a decade ago. Despite Fedora shipping fontconfig templates
maintained by Akira himself, our fontconfig state is, at best, poor.
PROPOSAL
I would like the fontconfig project to consider a configuration
language update based on the following proposal:
https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/200
It is based on the experience, gained, analysing hundreds of Fedora
fontconfig files, while streamlining the corresponding packaging.
This update is a mix of:
– syntax sugar enhancements
– tweaked fontconfig engine behaviour
– new features
It is presented both in traditional XML, and in YAML.
The proposal is only intended as documentation of the kind of thing
that would be useful to fontconfig users. I don’t care if this exact
syntax is adopted, or if it’s only partially implemented. Please
provide something that does the kind of thing I documented.
The current fontconfig syntax is awkward for simple traditional font
projects, and does not scale at all to the level required for modern
complex font project.
CONCISENESS
The proposal results in drastically more succinct config files, which
are easier to write, review and maintain. Conciseness is its own
feature.
For example, the description of IBM Plex Sans takes 106 lines in the
XML variant, and 27 lines in the YAML Variant. That may seem awful,
but my current incomplete attempt to describe Plex Sans with today’s
fontconfig syntax is more than 1700 lines long.
Given what I know of today’s fontconfig syntax, this attempt will never
achieve what’s in the proposal. The necessary logic is missing in the
fontconfig engine. It's not just a templating problem.
And, the missing logic is not complex. fontconfig is very close to
where it should be engine-side. Little things just snowball out of
control in presence of complex font projects.
Plex is not a pathological font project. On the contrary, it’s well
funded, and its authors clearly try to do the right thing. But, Plex
is modern, complex font project. That leaves a lot of room for small
mistakes.
ORDERING INDEPENDANCE
The proposal results in largely order-independant config files,
removing the need to agonize over proper ordering and ordering side-
effects, and removing the need to split configuration for a font family
over multiple files (that required specifying engine behaviour tweaks).
CORRECT ABSTRACTION LEVEL
The proposal avoids over-specifying low-level fontconfig behaviour,
leaving room to tweak the logic when new lessons are learnt, without
requiring the rewrite of thousands of configuration lines spread over
hundreds of files.
DOING THE CORRECT THING BY DEFAULT
The proposal makes some fixes automatic (generally, just applying
OpenType recommendations), so they're not forgotten half the time, and
we can all focus on more interesting things.
COMPATIBILITY
The proposal is backwards-compatible.
I hope you’ll find it interesting.
Best regards,
--
Nicolas Mailhot