Le 2019-09-13 10:39, Kevin Kofler a écrit :
Nicolas Mailhot via devel wrote:
The correct thing would have been never to create a narrow liberation
subpackage in the first place since narrow is just a face of a font
(like bold).
In theory, in an ideal world, that makes sense. But in practice, M$
ships
separate "Arial" and "Arial Narrow" fonts which are used in that form
in
thousands of documents worldwide, and we need to be compatible with
that.
That's an historical artefact, that made sense when everyone used the
same dozen font on windows, and when each and everyone of them could be
treated as a special case. Nowadays, even on Linux (what a change a
decade made) the font catalog is huge, and font processing *MUST* be
generic to scale.
So there need to be 2 separate fonts.
No, what we need is to have a narrow set of liberation sans faces
installed with the rest of the liberation sans. That's not the same
thing as enshrining windows 95 style ways of deploying fonts. (windows
95 was engineered around truetype limitations which have been solved in
opentype a long time ago; modern truetype is opentype).
And the reason why the 2 Liberation Sans variants (plain and Narrow)
are now
in separate packages is that Liberation 2 does not ship Liberation Sans
Narrow anymore, because it is not part of the set of fonts Google
bought.
And nothing prevents either using a src.rpm with two sources, or making
a liberations-sans-narrow that supplements the base liberation-sans
package, or making liberation-sans-fonts depend directly on
liberation-sans-narrow > version. All of which result in a working
standard generic font(liberationsans) dep.
Point being, apps should not hardcode in their deps a specific
liberation package split, just require font(liberationsans) like for any
other font family, and let the people in charge of liberation deal with
liberation internals, without leaking those internals right and left.
The reason we have this breakage right now is that people though they
needn't bother applying a generic font model, that it would be simpler
to use legacy shortcuts, and that failed hard when liberation moved to
2. Which, should have been none of the app business in the first place.
And restoring the legacy shortcuts does not help mid and long term.
Regards,
--
Nicolas Mailhot
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
