n8willis/opentype-shaping-documents

What does it mean to apply a feature?

simoncozens opened this issue · 5 comments

simoncozens commented

Describe:

  • How the run is processed (first applied lookup ends processing at each glyph position)
  • Matching of pre- and post- context
  • The effect of lookup flags

etc.

mikeday commented

It would be great to have a spec for this, but note that there are some unresolved issues about how nested contextual substitutions are actually supposed to work:

yeslogic/allsorts#25

n8willis commented

Describe:

* How the run is processed (first applied lookup ends processing at each glyph position)

* Matching of pre- and post- context

* The effect of lookup flags

etc.

My knee-jerk reaction is that, while this is stuff that needs to be specified, it is also stuff that is more fundamental to implementing OpenType, at the basic, "non-shaping" (not OTL) level. That is, it would also apply to all the shaping-irrelevant features, up to and including cv and ss. So it seems like this is not exactly the place it should live.

@simoncozens Do you disagree?

simoncozens commented

My understanding of shaping is that it is precisely the process of applying OpenType lookups to a run of glyphs! So processing cvXX and ssXX features is also shaping. (Another way to say this is that shaping is what a shaping engine does.)

Lookup flags, pre- and post-context etc. only make sense in the context of OTL lookups. Where else would you put a description of them?

n8willis commented

Well, words can have nuances of meaning in addition to totally separate definitions. The way we're using it in this repo, "shaping" refers to script-support features and algorithms, whereas we're intentionally not getting into user-preference-level features. A la Adam's classification list. So there's occasional references to non-OTL features, but we've only barely grazed them — such as locl and ccmp — and that's where the HarfBuzz hb-ot-shape-complex-* code incorporates them. Not going anywhere near aalt, dtls, frac, rand, or a host of other registered features.

I guess I think that the details of how the context and flags work feels more like it should live in or by the specification of GSUB / GPOS and lookups themselves.

There's certainly a line to draw somewhere, right? We definitely do not want to duplicate info.

simoncozens commented

That's fine. If it's out of scope for what you're doing, I've cover it in CommonType. It just needs to be written down somewhere, and if someone else was planning to do it I wouldn't have to. ;-)