Le vendredi 13 septembre 2019 à 12:18 +0200, Kevin Kofler a écrit : > 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 what ? We will never display Arial and Arial Narrow for trademark reasons. What you see in font lists is not what is declared in the files themselves (first, because font files have several layers of naming, second, because both Linux and Windows rewrite what the font files declare, except for very very old legacy windows programs that are so dumb they use the raw values of the most obsolete and legacy layer of font naming; those programs will fail with Liberation any version because no Liberation font file was ever tagged with Arial within itself for legal reasons). We do not need to slavishly copy font list artefact in package naming (that's why apache is in a package named httpd) And so on. > 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. You're conflating package naming with font lists, and you're assuming fonts files have a single naming layer, when all opentype formats provide several layers of legacy naming to accomodate legacy apps. There's zip reason for the Fedora package naming and split to be built around legacy layers of naming and to force every single Fedora app to use windows 95 conventions. And even if the font files didn't include several layers of legacy naming, that's what fontconfig aliasing exists for. Your apps are using fontconfig aliasing since that's what tells them Arial is really Liberation Sans on Linux systems; the mecanism in fontconfig to tell apps Arial Narrow + Bold Italic is really Liberation Sans + Narrow Bold Italic, is exactly the same than to tell apps Arial Narrow + Bold Italic is really Liberation Sans Narrow + Bold Italic The font files can and do declare both Liberation Sans + Narrow Bold Italic and Liberation Sans Narrow + Bold Italic at different layers of opentype naming; you're only seing one of those in GUI font lists because there is not point of drowning users in font aliases, so apps choose one to display, and work with all of them internally. The legacy way of declaring Liberation Sans + Narrow Bold is actually forbidden by the opentype standard in its most recent layer of naming. > > 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. That's not how the tech works, the fact that the same font files are deployed in X Y or Z packages does not change the legal or technical content of those files. What you see as single font entries in font lists are a collection of font files assembled by fontconfig. > The only legal way to merge the fonts would be to stick to Liberation > 1 for > Liberation Sans too, Nope, because different faces of the same font family are deployed with different font files, so regardless of the packaging, Liberation Sans Narrow Bold will always exist in a different file that Liberation Sans Bold (unless you try to go ttc or otc, that no one except CJK font users ever tried to do, because of the huge legal and management hell of mixing different faces and font families in a simgle file). The legalities hit when you attempt to copy glyph or hinting material from Liberation Sans Bold v1 to Liberation Sans Bold v2, because Liberation Sans Bold is a single font face, that exists in a single font file. > 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. The reason we have this breakage right now is that people who should know better have provided the liberation packagers with bad advice, because they forgot that understanding packaging mecanisms, didn't dispense from undertanding the technical object being packaged. > That it is a > narrow variant of Liberation Sans is entirely irrelevant Nope, because since it is a variant of Liberation Sans, rpm font autoprovides apply, and using explicit package names when autoprovides exist never ended well. The correct way to do things (correct because it is future-proof and does not result in breakage in one or two releases) is to remove any dep on liberation-sans-fonts or liberation-sans-narrow-fonts in third party packages, have them require font(liberationsans) and let the liberation sans packagers manage font(liberationsans) deployment in one, two or n packages, with a main package dragging in other packages if they deem it necessary. And then the head package can obsolete any anterior version of the package(set), and the narrow faces may exist or not as separate packages. The root cause of the failure is the explicit reference to a separate narrow package in app packages, and it was compounded when, instead of cleaning up this reference, and get a clean simple and maintainable dependency graph, the Liberation packagers tried to make it exist again. > And since Liberation Sans Narrow is a different font It is not functionnally. Technically, a legacy artefact is still exposed. It will be cleaned up at the font format or the fontconfig layer sooner or later (as windows already does in the most recent of its text stacks). Use the correct naming (which is already available), it's the only one future-proof. Regards, -- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
