Hi Paul, Quoting Paul Gevers (2021-02-07 07:00:34) > On Mon, 21 Dec 2020 15:35:04 +0100 Jonas Smedegaard <d...@jones.dk> wrote: > > > > Setting severity to serious, as this package is not fit for > > > > release. > > > > > > Why do you think the package is not fit for release? Because it > > > did not have a maintainer upload for the last 10 years? It is > > > static font data, after all? Or because it does not follow a > > > naming convention that isn't even Debian policy? > > > > Because two font packages provide same font - i.e. registers same > > font id with fontconfig. > > And what are the consequences of that? Please assume I have no clue > how fontconfig works at all.
When you write and proof-read a document, you expect that document to "stay the same" when you later open it and print it again. If the document does not embed the fonts used, but only reference them, then technically it most likely use the "font ID" as reference, rather than e.g. a full file path to the font file. (this is essentially what fontconfig does: offers an abstraction layer to locate the font path from its identifier). If two font packages provide same font IDs, then your system cannot reliably have your documents "stay the same". The original purpose of both gsfonts and fonts-urw-base35 is a set of fonts that as first priority has same size as a set of fonts part of the Postscript specification, and only as secondary priority the fonts should "look nice". At some point, gsfonts evolved, most notably for users was the addition of glyphs to render cyrillic characters (as used in slavic countries like Russia). Unfortunately it was later discovered that also other changes had crept in affecting the shape of characters - i.e. the primary purpose of that font set. Those who use gsfonts for its documented purpose of "look-alike fonts of the Adobe PostScript fonts" should consider gsfonts broken and should instead use fonts-urw-base35. Those who use gsfonts for its visual beauty and extended coverage should arguably instead use tex-gyre (which involves refreshing documents to use different identifiers). Today, those who rely on "look-alike fonts of the Adobe PostScript fonts" will have the proper functionality when fonts-urw-base35 is installed and gsfonts is not installed. They will randomly/undefined have a broken functionality if gsfonts is installed. Yes, the opposite is true for those who rely on gsfonts to do something else than it promises in its package description - but if we want such stability, then we must never change fonts, only *add* new versions of same-named fonts - that is not how Debian is structured. > > Feel free to lower severity or repurpose as a wishlist request to > > document what is notable about this font over fonts-urw-base35, or > > whatever - I have no strong attachment to this issue, it can linger > > for another 10 years without me noticing much... > > Your comment suggest that we should ignore this issue for bullseye. > There's quite some work to get it removed, it's late in the release cycle. That remark was made as a reply to the maintainer of fonts-urw-base35 who argued that non-documented secondary features of gsfonts should be treated as primary for that package. If we want to permit fonts to evolve while staying true to their stated primary purpose, then it is my understanding that it is doable by simply a) having fonts-urw-base35 provide/break/replace gsfonts, and then drop gsfonts. It is my understanding that it is only "quite some work" if we want to honor whatever shape a font has at some release. I.e. the equivalent of honoring "...but my code _needs_ libssl 1.0, regardless if that breaks all libssl 1.1 uses". - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
