An exchangeable text representation of TrueType hinting?

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 SeifertGeorg Seifert Posts: 466
    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 InvisBelleve Invis Posts: 192
    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 InvisBelleve Invis Posts: 192
    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 PhinneyThomas Phinney Posts: 776
    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 KutilekJens Kutilek Posts: 114
    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 InvisBelleve Invis Posts: 192
    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".
Sign In or Register to comment.