https://bugzilla.redhat.com/show_bug.cgi?id=1806272
Nicolas Mailhot <nicolas.mailhot(a)laposte.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tagoh(a)redhat.com
--- Comment #19 from Nicolas Mailhot <nicolas.mailhot(a)laposte.net> ---
(In reply to Parag Nemade from comment #18)
we have langpacks-core-fonts-<langcode> packages to use. They
provide
pre-defined default font for that <langcode>. If packages want to use
particular font package they need to pull it explicitly. But if there is no
such particular font demand then default langpacks-core-font-<langocode> can
be used.
Sure, but here we have the case where <langcode> is not defined (the package
wants some default fonts installed, it does not care which ones, as long as
some default is installed).
What dep should the package use in this case? I can add the generic answer to
this question to guidelines, but I need an answer i18n, as maintainer of the
distribution default font lists, is comfortable with
Yesterday I first tried to use new guidelines and
convert some fonts packages and there I found about change in directory
structure and fontconfig file format.
The new fontconfig format is not part of the guidelines change, you can use the
usual format, and the usual format is the one documented in guidelines and
default templates. Just set %fontconfs not %fontconfsngs.
The new format exists in my own packages as a stopgap demonstrator because
Akira wanted proof the current fontconfig format does not scale to current
needs. Also, there was no way in hell I could write and check and proof and
maintain by hand the multi-hundred/multi-thousand lines of configuration
required by some of the packaged fonts. Lastly, the current syntax does not
work at all unless you have perfect knowledge of the styles that will be
declared by your font files, so it needs brittle workarounds in %install to
generate a conf file that will only work with the exact files installed.
Simple font packages can be handled with the legacy syntax (though it is overly
verbose and painful). Complex (rich fonts) like Plex Sans, Merriweather, Droid,
Noto, etc are quite impossible to maintain without something like it.
Also, I don’t intend to maintain the new syntax generator long term. Fontconfig
syntax fixes belong in fontconfig. The generator is already way more complex
than I imagined at first, because font makers are behaving way worse than,
making current fontconfig syntax that more inadequate and harder to workaround
outside the engine itself.
--
You are receiving this mail because:
You are on the CC list for the bug.