On Monday, February 26, 2024 10:20:54 PM MST Paul Wise wrote: > On Mon, 2024-02-26 at 14:27 -0700, Soren Stoutner wrote: > > My hesitancy for doing that is that the names of the fonts will > > change. For example, 'SourceSans3-Regular.otf' will become > > 'SourceSans4-Regular.otf'. This has already happened once, when > > the fonts changed from 'SourceSansPro-Regular.otf' to 'SourceSans3- > > Regular.otf'. > > This generally has little effect on Debian at least, because > fonts are meant to be found by their font name not their file name. I would generally agree with you, but in this case it is different for two reasons. 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. 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. 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. Otherwise, it would be difficult to ship both source-sans-3 and a possible future source- sans-4 at the same time, as the source-sans source package would move to a future version and you can’t build both versions of the font from a single commit tag. However, if the source packages are versioned, you could leave source-sans-3 at the latest version 3 commit and just ignore or remove the watch file telling you that updates are available. But the OFL license with a reserved name makes this even more difficult, because different versions of AFDKO are likely to produce slightly different font outputs. So, even if the version built at the time the font ships matches upstream, future rebuilds probably won’t. The more I think about this, unless I am somehow able to get Adobe to authorize a rebuild exception (does anyone have example text of what they would need to add to the license to do this?), the best way forward might be the following: "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.” 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? Or, perhaps, this is turning into more work than it is worth. Electrum actually gets along just fine without Source Sans. It is only used in an optional plugin that was broken upstream for a long time without anyone noticing and which falls back to a default font without any issue. I figured it would be easy to package and would be nice to use what upstream is using, but it turns out that was incorrect. -- Soren Stoutner soren@debian.org
Attachment:
signature.asc
Description: This is a digitally signed message part.