An exchangeable text representation of TrueType hinting?

Belleve Invis
Belleve Invis Posts: 269
in Type Design Technique & Theory
The current TrueType hints are all written in private formats making them

  • Hard to combine
  • Hard to exchange
  • Hard to maintain

Could we have an exchangeable format to describe the hints? Given that designers are not going to write assembly black magics we only need to deal with:
  • CVTs
  • Glyph hints, described in some high-level representation

Comments

  • Georg Seifert
    Georg Seifert Posts: 680
    There are much more things you could do with TT instructions. We could find a set of high level hints that would work for most situations but the resulting byte code will very much depend on the compiler. So I’m not sure how useful it would be at the end.
  • Belleve Invis
    Belleve Invis Posts: 269
    The following code is my attempt to define a "universal" set about hinting. I use some principles in Haskell and Idris like Monads...
    https://gist.github.com/be5invis/d78ec969e45f83ecb7d92c527237a8c2


  • Belleve Invis
    Belleve Invis Posts: 269
    Georg Seifert said:
    There are much more things you could do with TT instructions. We could find a set of high level hints that would work for most situations but the resulting byte code will very much depend on the compiler. So I’m not sure how useful it would be at the end.
    However maintaining a lot of assembly is definitely a disaster. If our high-level part can provide a sufficient set of instructions then we can finally get rid of assembly and deal with them only.
  • Thomas Phinney
    Thomas Phinney Posts: 3,064
    I would expect there would be differences of opinion about what should be included in the high-level part, and just how "high-level" it should be.

  • Jens Kutilek
    Jens Kutilek Posts: 379
    I wrote down my thoughts about hinting representations in this comment on the UFO spec: https://github.com/unified-font-object/ufo-spec/issues/43

    There seems to be not too much interest in this, telling from the lack of replies ...
  • Belleve Invis
    Belleve Invis Posts: 269
    Thomas Phinney said:
    I would expect there would be differences of opinion about what should be included in the high-level part, and just how "high-level" it should be.

    “High” means that it could be easily maintained, like: parsing, generation, compiling into TT Instruction, merging, being edited in the visual UI, subsetting, etc.
    TT Instruction is diffidently "low level".

Categories