Unimplement[ed,able] spots in the OpenType spec

Nathan Willis
Nathan Willis Posts: 10
in Font Technology
This Twitter thread from earlier in the week (about the Component class in GDEF, and whether it really is used) started me thinking — there are a number of elements in the OpenType specification that are pretty widely recognized as being "not practically implementable" for one reason or another, such as lack of detail or, perhaps, because they were a little aspirational when they were first added, and things went a different direction....

For example, the JSTF table or the `rand` feature. But they tend to emerge in discussions rather arbitrarily & unpredictably when someone bumps into them.

So I wonder: is there a somewhat-current list somewhere of those bits & gaps? The things that are listed in the spec, but cannot actually be supported IRL? Other than digging through HarfBuzz source code or font-editor documentation, that is.

Or, if there's not such a list, then alternatively please feel free to chime in with replies and perhaps have a casual one emerge below....

(I do realize that there's a lot of personal interpretation in calling something "impractical" or "not implementable"; I'm totally fine with those caveats being assumed and nobody will take such a comment as being official or definitive. Unless you want to make a case for yours.)
Tagged:

Comments

  • Simon Cozens
    Simon Cozens Posts: 804
    In terms of OpenType features, if I were having a clean out of the ones that never really made it, I'd get rid of falt, hang, opbd, ltbd/rtbd, smpl, tnam, valt, and vrt2.
  • Nathan Willis
    Nathan Willis Posts: 10
    Simon Cozens said:
    In terms of OpenType features, if I were having a clean out of the ones that never really made it, I'd get rid of falt, hang, opbd, ltbd/rtbd, smpl, tnam, valt, and vrt2.

    Do you mean `hngl` there?
  • Simon Cozens
    Simon Cozens Posts: 804
    Yes.
  • John Hudson
    John Hudson Posts: 3,500
    In terms of OpenType features, if I were having a clean out of the ones that never really made it, I'd get rid of falt, hang, opbd, ltbd/rtbd, smpl, tnam, valt, and vrt2.
    Don’t forget ‘size’. Probably the most batshit conceptual feature.
  • Erwin Denissen
    Erwin Denissen Posts: 315
    John Hudson said:
    Don’t forget ‘size’. Probably the most batshit conceptual feature.
    Sort of related is OS/2 version 5, as that added two fields (usLowerOpticalPointSize and usUpperOpticalPointSize) that are now superseded by the STAT table.
  • John Hudson
    John Hudson Posts: 3,500
    Correct. The OS/2 v5 size fields were under-specified in that they did not provide for complex family mappings. They could have been made to work, with some name table additions, but STAT is a better mechanism.

Categories