Two thoughts about Google after Typographics

13»

Comments

  • While the conceptual overlap between "revival" and "technical debt" is somewhat interesting, it's a big stretch to equate the two so quickly in practice.
  • Although the parallel isn't entirely... parallel, it's certainly not a big stretch; understanding third-party technique (and more to the point here, potentially correcting it) is trivial; the only real challenge is understanding intent.

    Also, making an entire Latin font to deliver a versatile non-Latin is often essentially a disservice to users. This was a central point in my TypeCon 2014 talk.
  • Dave Crossland
    Dave Crossland Posts: 1,431
    edited July 2016
    SiDaniels said:
    Are the Google fonts really open source, if there are no source files available? "Open Binary" maybe? ;-)
    Its an interesting question for me on 2 levels. 

    First, abstractly: Unlike compiled programs, and like (unobfuscated) interpreted programs, fonts are inherently in "source" form, where source is defined as the "preferred form of modification." It is pretty easy to convert quadratics to cubics and carry on; it is pretty easy to convert post-remove-overlap contours into overlapping ones. Easy, but tedious, and perhaps only a small matter of programming. I discuss this in my MA Typeface Design dissertation.

    Secondly, concretely about Google Fonts: The old code.google.com repo included source files for almost all families in whatever format the designer provided them in - typically either VFB or SFD.

    A couple of years ago code.google.com began to be shuttered, and there was a transition to github.com, and in this transition I rethought things; a single repo, with hundreds of projects' source files, didn't make much sense to me, I thought it better to have the 'upstream' projects have their own github repos with whatever source files they like, under the usernames/orgs of the actual designers, and only include the binaries that the Google Fonts API serves in the github.com/google/fonts repo. 

    All the new projects follow this, but sadly a lot of projects don't have a home on Github yet, and no one has touched them in years, and now their source files that were available on code.google.com are somewhat tricky to reach. 

    I hope to address this very soon. I do have source files for almost all libre font projects, and I expect to convert the VFBs to .glyphs and get them all up on Github. 

    I expect that doing this, consolidating the source format and build process, and setting new standards for fonts in the collection around glyph sets, glyph naming and encoding, diacritics, spacing and kerning, will alleviate the problem that John points out. 

    (The glyphs format is about as open as UFO, and both are today partially supported by fontmake and TruFont, and I expect that support to improve to 100% for both formats over time. I do wish that FontForge, Glyphr Studio or Metapolator would have taken off to the point that they would be suitable as the central editors to build the libre font movement around, but sadly that isn't the case. Instead, since Glyphs is now this decade's pole position editor, dethroning FontLab and Fontographer and Ikarus that previous held that position, and the Glyphs format is open, and a libre editor is supporting it, then I am comfortable with using that format for libre fonts.)