This Twitter discussion got me doubting my beliefs about what constitutes the "source" in an open source font project.
To me the source files are the
- scripts (if any)
- feature files
- maybe even svg files if the glyphs (in this case icons) were drawn in another program
- the actual font stored the format it was saved and not generated (in this case OTF)
Am I being too picky/strict or what do you guys think?
https://twitter.com/larsenwork/status/626711927989895168 (Didn't know which category to put this in)
Comments
For example I’d not consider SVG files to be source files unless the glyphs in the font are directly imported from them without modification, otherwise they just represent part of the project history not the current source since any required modification will not be done on them.
Since its not difficult to recreate overlapping contours and guidelines and group glyphs with colors and make a legend, its generally considered trivial too. I believe this is was considered by the SIL authors when they decided not to include a source provision requirement in the OFL; not having that requirement simplifies the administration of libre font projects, and is thus a net win.
However, I see a trend of richer and richer font editor native files, where not just metadata but real modification data is lost in binary compilation. For example, if you take a binary font and modify it, you will inevitable save your work in your editor's native file format, which will include additional data not included in a binary file. As editors add productivity features, like Glyphs' Smart Components, then this extra data goes beyond metadata and becomes more important to provide.
Libre licenses define source, as you say, as 'preferred form of modification' and I like this definition for thinking about this topic. With font projects, if you have all the files and git history associated with some font binaries, you might prefer to make modifications on the binaries (with TTX), on the FDK compiler files (font.ufo, etc) to generate new binaries, or on the drawing files (eg the svgs mentioned above, or glyphs files) to generate new compiler files and then new binaries. It all depends on the nature of the modification and the compilation process.
For icon fonts, such metadata is less important, and it seems that Font Awesome is developed with the binary as the authoritative source format. So, Andreas, I do think SIL's laissez faire approach is best; when you said "you are not a true open source project" that is likely to annoy them and is counterproductive. It would be better to make your hybrid icon/text font with your own vision of full sources and show rather than tell them how it is better
For the Lato font files, the sources are ultimately a small set of FontLab VFBs plus some 15+ Python and other tools that participate in the building process. Most of the font's metadata, OpenType Layout features, naming, hinting etc. is generated by code during production. Basically, code adds layers after layers of information.
The problem with that approach is that currently, we have no preferred form of modification We have several slightly conflicting ones.
I guess it depends on the scope of modification you want to do. You seem to be looking at it from the engineering angle here.
I’d say for bigger design modifications it is absolutely necessary to start with something other than the font itself.
For example, the Fira System Font Replacement project would not have been possible starting from the available fonts. Ralph du Carrois was so kind to let me use his Glyphs source files which are usually not published. That way I could see the original masters structure, interpolation settings and exceptions. None of these would be available in a bunch of SFNT files.
I didn’t even do a «real» design modification, but I did a complete re-interpolation of Fira to match the Neue Helvetica weights each font replaces, change default figures etc. I just needed to write a small Python script to reconfigure the original Glyphs sources, so when Fira gets an update, I just apply the Python script again and have an updated version of the System fonts.
Starting from SFNT would be impossible. A nightmare to guess the interpolation masters from the final fonts, make them interpolation compatible again, check what has changed between versions of Fira, ...
The Carrois/Spiekermann team really have perfected their process of doing a lot with the smallest possible starting point, if I may divulge this kind of information Similar to Fira was the process for the new FF Real Head/FF Real Text, which also started with a single Glyphs source file, and ends up with a couple of hundred font files in the different formats and language versions.
1 Glyphs source file with 5 (iirc) masters is transmogrified to generate 24 instances (12 head, 12 text) with full Latin Extended language support, plus 24 for Western language subsets, plus 48 WOFFs (2 language versions) plus 96 OT-TTF (2 language versions, separate small caps), plus 24 Web-TTFs (1 language version to be subset by the consuming web shop systems).
It’s not as easy as it sounds though, only the design part and the initial splitting takes place in Glyphs, and it still took over hundred of engineering and QA hours after that. I was the Font Engineer for this project and it kept me busy a couple of weeks.
For example, this is the definition of letter "s":
This code snippet defines the skeleton of letter "s", as well as the offset of the "inner" and "outer" edges of the stroke. The program will calculate all the control points and write the final shape into a .ttf file.