Paul Wise wrote: > The issue isn't that they currently use proprietary software to > convert to OTF format. The issue is that there is no Free Software in > Debian main that can build the OTF from source. This is a clear > violation of Debian policy and that indicates the package needs to be > in contrib.
But the OTF format itself is just as suitable a source format for fonts as any other format. Why is it so important what upstream has chosen? It is not that font composition is a human-readable-to-binary-one-way-road like compilation C source files into object code or HTML documentation to PDF. > In this case, if you look at the commits to the github repo, there is > a clear canonical source format and that is the proprietary Glyphsapp > format that can only be converted to OTF by the proprietary Glyphsapp > software. Thought experiment: Would it feel more "correct" if I forked the firacode upstream project, converted their OTF files into fontforge's SFD format, checked these into a GIT repo and then distributed these? > I would vastly prefer the correct source of PNG images to be > distributed in source packages and the PNG images created at build > time to the current, fairly horrible, situation. Choice of source > format is up to upstream though. Another thought experiment: We have a fairly prominent example of binary-only Type1 fonts available in the gsfonts package. They are licensed under the GPL, so there is even a "preferred form for modification" term that applies to them. Nobody knows how URW++ created these fonts and what tools they used, nevertheless a number of viable forks have been developed from them, among them GNU FreeFont and TeX Gyre. Now, what would happen if URW++ suddenly revealed that they used proprietary software to create the fonts and that the files that we have are not the canonical sources. Why should it make a difference at all? - Fabian