> That being said, if the existing build script produces a font binary that
> is functionally identical to the font binaries (a different test than
> bit-for-bit identical), I believe that's enough, and if future updates to
> Adobe's own tools make that no longer hold true, I'm confident they would
> consider that a bug that needed fixing.
This is what SIL’s website says about rebuilding the fonts.
https://openfontlicense.org/how-to-modify-ofl-fonts/
"5.9 Do font rebuilds require a name change? Do I have to change the name of the font when my packaging workflow includes a full rebuild from source?"
"Yes, all rebuilds which change the font data and the smart code are Modified Versions and the requirements of the OFL apply: you need to respect what the Author(s) have chosen in terms of Reserved Font Names. However if a package (or installer) is simply a wrapper or a compressed structure around the final font - leaving them intact on the inside - then no name change is required. Please get in touch with the author(s) and copyright holder(s) to inquire about the presence of font sources beyond the final font file(s) and the recommended build path. That build path may very well be non-trivial and hard to reproduce accurately by the maintainer. If a full font build path is made available by the upstream author(s) please be aware that any regressions and changes you may introduce when doing a rebuild for packaging purposes is your responsibility as a package maintainer since you are effectively creating a separate branch. You should make it very clear to your users that your rebuilt version is not the canonical one from upstream.”
Yeah, that's a very new site that SIL has put up. On the whole, easier to find, easier to read, but it does have a bit less technical info.
Does anyone know any way to check if the fonts have the same “font data” in any other way besides checking if they are bit-for-bit identical?
Unfortunately, it's not an easily-unambiguously-answered question, it's a "people will debate this" question.
Four things are listed there: character set coverage, smart-font behavior, preservation of visual quality, and preservation of author-project-license metadata. Other "optimizations" are said to be OK, but even there it's phrased as "it's very likely" to be considered okay, rather than "you can be sure."
It's *my* professional opinion that there are quite a few bits and bytes that downstream could improve on that do not constitute changes to "functional equivalence". Trivial example: CFF subroutines, which could save a lot of space. There are also quite a few redundant fields scattered around the format, and there are a number of system-integration fields that would make fonts more usable (such as indicating language and script support) but do not add or remove functionality. There is also the ambiguity of whether fixing an obvious bug like a bad URL in the metadata (or replacing the old OFL URL with the new one) would be considered changing functional equivalence.
That said, absolutely what matters more in the practical sense is where the upstream copyright holder stands on those things (as the SIL page says, compliance starts with how the upstream designer feels). Me trying to convince others about it is a very-long-term effort.... I originally proposed that RFN-violation usertag specifically to draw more people's attention to these sorts of problems and to how many Debian-packaged fonts have RFNs, including the ones that were getting lost in the packaging process. I don't know if that did any good.
"If the font cannot be built from source using only packages in Debian main, move this package to contrib and use the upstream build.”
This could be done fairly easily by just shipping the compiled fonts that upstream ships. But I am not sure I want to invest energy into a font that isn’t part of main.
https://github.com/adobe-fonts/source-sans
--
Well, personally I would encourage you to keep with it, even if it goes to contrib. I think the fonts are well-made, and they are quite popular out in the wide world of fonts. It helps all Debian users to be able to access them (whether when they receive a document using them, or they want to make something using them so other people who get the fonts through another means can see their work as intended) and to get them from a trustworthy source that they know won't vanish overnight. Not that that's likely with Adobe, but still.
I think it's pure-benefit for people not to have to give up access, and convenient access, to well-made fonts when running a free OS, even though not every font can be in the default install.
It's a broader question how we should make finding the fonts in the different archives easier without blurring over important concerns, though. I'd like the various GUI font managers to highlight RFNs, for instance, but of course that doesn't do anything for helping the user know what is or isn't available to them in the package archives....