Group for shaper behavior specification

[simoncozens]

I'd like to form a group to produce a specification for the behaviour of a MSOT/OFF shaping engine. Currently there is some documentation around shaping behaviour, but this is incomplete:

• https://github.com/n8willis/opentype-shaping-documents describes complex shaper behaviors, but not the standard shaper.
• Microsoft's "Developing OpenType Fonts for"... documentation contains, in my opinion, a number of inaccuracies.

In each case, this documentation describes the behavior of existing implementations, but does not act as normative specification for how conformant implementations should behave.

I am ambivalent as to whether the deliverables are ultimately to be recommended for inclusion in OFF; I don't think that should necessarily be a consideration at this stage. I feel a W3 Working Group is probably the right home for such a specification effort, whether a new or an existing one. Suggestions of potentially suitable existing WGs are welcome.

[tiroj]

Can we break this down a bit further and define what the group’s output would be in more detail?

There are a lot of levels to text layout/shaping and one of the problems with current specs such as Microsoft's 'Developing OpenType Fonts for...' is that they only spec a slice of the process, with a lot of presumptions about what happens before and after. We need a start-to-finish spec. We're also missing a lower level specification for how to correctly process and apply OTL lookup types, and a test suite for these, so it is currently possible to perform run analysis and script shaping in a consistent way and still get different output because lower level libraries are not processing lookups the same way.

[simoncozens]

@frivoal Just for planning how to move this forward, if the expected deliverable is a specification (or set of specifications), should the forum be a WG or can a CG produce specs? I’m thinking the rigour of a WG may be a better fit, but the ability to spin up a CG quickly is tempting to get things started.

[simoncozens]

As for @tiroj’s idea, completely agree. I think it may be possible to attack the problem space piecemeal with a set of “mini-specs” initially (I anticipate each script-specific shaper needing its own mini-spec, and even granular processes such as OpenType normalisation beginning with mini-specs to effectively capture knowledge and practice) with a view to ultimately putting them together as a complete end to end spec. @n8willis’ documents, if sufficiently formalised, can be some of the pieces in the puzzle.

[lianghai]

@simoncozens, a CG can certainly produce its own specifications, just not in W3C’s recommendation/standard track. And the CG mechanism is designed specifically so the advance of a specification to the recommendation track can happen. Trying to create a WG for a specification before having already attracted enough participation will be too much burden.

[simoncozens]

OK, I shall push ahead on the basis that this should be a CG. Draft charter soon, thanks to @davelab6.

[frivoal]

Right. The boundary is a little fuzzy, but the general approach is to start a CG until you have enough of a spec and of a community working on the spec that you're reasonably sure that you understand the bounds of the problem you're working on, and that the project is reasonably likely to not fall apart. At the point, investing in creating a WG makes sense. The stage before that is generally referred to as "incubation" in W3C parlance.

Attempt to start a WG too early, and you'll raise many eye brows, with people wondering if you're really sure of what you're doing, and asking you to accumulate a bit more evidence that you're onto something first.

Do it too late, and people will be annoyed that you're claiming to want to create a consensus-based standard even though everything is already set in stone.

Finding the right balance can therefore be a bit subtle. But for now, we're certainly in the early phase, so a CG makes sense.

[n8willis]

In each case, this documentation describes the behavior of existing implementations, but does not act as normative specification for how conformant implementations should behave.

Isn't the distinction between these two italicized things essentially just "where they come from"? I mean, if the "owner" or "authority everyone acknowledged" were to say that a document is a specification, then it is, whereas otherwise the same document would just be a description?

I ask because it seems like that's the distinction to me — and it seems like one of the goals of the CG effort is to form the authority-of-interested-folks that'd be appropriate to give the approval.

But, if I'm misunderstanding you, I'd be interested to know. Definitely I understand that some specifications out there utilize a lot of "SHALL" and "MUST" language, so that can be different (and my repo that you pointed to here didn't take that approach), but that seems more like a lower-level stylistic thing. Just wanting clarification.

[simoncozens]

I ask because it seems like that's the distinction to me — and it seems like one of the goals of the CG effort is to form the authority-of-interested-folks that'd be appropriate to give the approval.

Well, sure. And your documentation is pretty close to that. What makes it a spec rather than someone's notes on the process is securing consensus from implementors that this is what we as a community believe OFF shaping to be.