On Mon, 2024-02-26 at 23:02 -0700, Soren Stoutner wrote: > 1. Source Sans’ primary purpose as described upstream is as a font to be used > in user interfaces. When programs display fonts for their user interfaces, > they are usually selecting them by their file names. I think that most packages in Debian would do this via the font name and fontconfig/pango/etc these days. That said there may be some games that use older libraries that cannot use fontconfig and cannot render multiple fonts in one string that may be affected by filename changes. Probably we should work towards replacing use of those libraries. > 2. In the case of Source Sans, it isn’t just the file name that changes with > major versions, but also the font name. So, for example, if I create a > LibreOffice document and select the font, the font name is Source Sans 3. In > the future, if they ever move to version 4, the font name will become Source > Sans 4. Which will, of course, break any document that is using the font. > > As I mentioned before, this seems like insanity. But upstream apparently > doesn’t feel that way. Partially because they don’t really intend the font to > be used in documents, so it doesn’t appear that they care if those break. From what Nathan says, you can think of this version number as a SONAME for the font. If it changes then documents aren't compatible any more, so they should use the old name until they are ported to the new one. > Assuming all the other problems get addressed, perhaps it would be best to > move the source package name back to the versioned source-sans-3. Definitely, since you will want both versions packaged probably. > "Build the font from source using tools from Debian main during the package > build but distribute the upstream build in the binary package instead. In this > case it is not required to move the font to contrib.” While technically this does meet ftp-master requirements, it is really just ridiculous and I hope that future OFL versions fix this issue by at least defining compatibility requirements for rebuilt versions. > To do this I would need to combine information from two different Git sources > or tarballs (as they don’t store the source code and the compiled fonts in the > same place). Qtwebengine-opensource-src does this, but it is a pretty messy > process (see get-orig-source in their rules file). Is anyone aware of an > easier way to make this happen? Debian source packages can use multiple tarballs, one primary one and multiple secondary ones unpacked under specific directory names. So I suggest using the primary tarball for the source and the binaries in a secondary tarball unpacked into upstream-build/ or similar. > Or, perhaps, this is turning into more work than it is worth. That is generally what I think about any font with an RFN, especially since Google Fonts exists and the fnt package manager for it exists. -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part