Nicolas Mailhot via devel wrote:
> 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.
But the fonts shipped with M$ Windows or M$ Office are still by far the most
widely used. And those are referenced as "Arial" and "Arial Narrow". So we
NEED separate Liberation Sans and Liberation Sans Narrow fonts that can be
used as drop-in font substitutes for these.
>> 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).
No, sorry. We need to be compatible with existing documents and (in the case
of WINE) applications. This is the whole point of the Liberation fonts.
And this is only the technical part, there is also a legal issue:
> 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.
Liberation 1 and Liberation 2 are under different, incompatible licenses. It
would be illegal to merge the 2 fonts into a single font.
The only legal way to merge the fonts would be to stick to Liberation 1 for
Liberation Sans too, which the Liberation team does not want to do for
various reasons.
> 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.
This is absolutely wrong. The reason we have this breakage right now is
because somebody decided that liberation-fonts should Obsolete and Provide
liberation-narrow-fonts without actually providing that font. That it is a
narrow variant of Liberation Sans is entirely irrelevant, it could have been
called Fred or Foo and it would still be the same issue. A package should
NEVER claim to Obsolete and Provide foo-fonts if it does not actually
contain the font Foo.
In addition, the Obsoletes was versioned in a ridiculous way, as
< 1:2.0, when there was never such a version of liberation-narrow-fonts (it
did not even have an Epoch). So bumping over the Obsoletes required bumping
the Epoch from unspecified (0) to 2 (because the Version is still 1.x and
will remain so for the foreseeable future, because Liberation 2 does NOT
include this font).
And finally, unlike the old YUM, DNF also processes Obsoletes from old
versions of packages in the GA repositories, so an update can no longer
safely withdraw an Obsoletes. This is a DNF issue and we need a solution in
DNF, but the DNF developers refuse to acknowledge this as a bug in DNF.
And since Liberation Sans Narrow is a different font, the applications would
need to require font(liberationsansnarrow), not font(liberationsans), and so
they would still be hit by the Obsoletes mess (because only
liberation-narrow-fonts actually provides that). Again, your ideal world in
which narrow is a natively supported property of a merged font is NOT the
world we live in! At least not now.
Kevin Kofler
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
