Would you consider OTF "source" for e.g. an open source font project?

Andreas Larsen
Andreas Larsen Posts: 22
edited July 2015 in Technique and Theory
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
  1. scripts (if any)
  2. feature files
  3. maybe even svg files if the glyphs (in this case icons) were drawn in another program 
  4. 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

  • James Puckett
    James Puckett Posts: 1,993
    OTF is not a source format anymore than a compiled C++ program is a source format.
  • Khaled Hosny
    Khaled Hosny Posts: 289
    The source is usually defined as the preferred form for modification, in other words if I’m to send you a contribution what file should I modify and send to you? I have worked on font projects where the SFNT files were the only files used and all modifications were done directly on them, so that is the source as far as we are concerned.

    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.
  • Khaled Hosny
    Khaled Hosny Posts: 289
    I don’t think the compiled C++ comparison is fair, for most font there is not much lost information when you start with an SFNT file as compared to starting with a compiled program, and the missing information is usually secondary. For example in a font project I’m working on with another collaborator who is using VOLT to do the OT layout, I first tried writing a VOLT to FEA converter but then found it easer for me to just used the “shipped” VOLT font as my starting point and just let my font editor decompile the layout code for me, and I haven’t missed anything (OK, I don’t get the more explanatory lookup and glyph groups names, but that is hardly a deal breaker).
  • Dave Crossland
    Dave Crossland Posts: 1,429
    edited August 2015
    I don’t get the more explanatory lookup and glyph groups names, but that is hardly a deal breaker
    Right, you lost some trivial metadata. Generic metadata shared by code and fonts - comments and structure - aid us in making sense of the project, but are somewhat trivial too. The full git history is another kind of trivial metadata; 'git blame' makes for better understanding of the code, but none of it is really required to make modifications, so its provision isn't mandated by any libre license. 

    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 :)
  • Adam Twardoch
    Adam Twardoch Posts: 515
    There currently isn't a single source format that is able to store sources of all kinds of data that can end up in an SFNT font. There are several monochrome and color glyph flavors, several layout models, several hinting technologies, and for each of these models, there are multiple tools that can produce them — none truly all-encompassing.

    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.
  • Georg Seifert
    Georg Seifert Posts: 674
    There might not be a preferred format but you should pick the one that fits your project and workflow.
  • Deleted Account
    Deleted Account Posts: 739
    That ain't workin'.:)
  • Belleve Invis
    Belleve Invis Posts: 269
    edited October 2015
    Well for Iosevka there ARE source code in the repository: https://github.com/be5invis/Iosevka.

    For example, this is the definition of letter "s":
    create-glyph 's' : glyph-construction
	set-width WIDTH
	assign-unicode 's'
	include eMarks
	define smooth : adviceSSmooth XH (-1)
	include : spiro
		widths.lhs
		g4   RIGHTSB (XH - SHOOK)
		hookstart XO SBALANCE
		g4   SB (XH - smooth)
		alsothru 0.5 0.5 [widths (ESS / 2) (ESS / 2)]
		g4   RIGHTSB (smooth) [widths 0 STROKE]
		hookend O SBALANCE
		g4   SB SHOOK
    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.

Categories