[MPEG-OTSPEC] Defining the text shaping working group’s scope

[suzuki toshiya]

Dear John,

On 2020/07/31 1:23, John Hudson wrote:
> On 29072020 8:56 pm, suzuki toshiya wrote:
>>> 1. Technology Documentation
>>> Describes the underlying technologies script implementations rely on. For example, OpenType, shaping engines.
>> Indeed! Detailed information about the existing implementations of OpenType is really really important for the font-related software engineers. I remember, in the past, there was a rumor of a discussion whether the documents of the script-dependent shaping mechanism of OpenType (currently provided by Microsoft) should be a part of ISO specs (or ISO TR), or not, but I cannot remember the conclusion. If the Text Shaping WG is created under the current JTC1/SC29/WG11 font AHG, the WG will make such ISO document? If it is created under Unicode, the WG will make such document as a part of Unicode standard (or UTR)? Either way, I'm sure that it would be an admirable decision.
> 
> Documenting script shaping engine behaviour is important, but I think we need to start at a lower level, and provide the missing OTL implementation specification and a reference implementation. Where different shaping environments (i.e. a shaping engine in combination with the software within which it is operating) produce different results, this tends to be because of differing interpretation of the OTL table data and understanding of what to do with that data.

Oh, thank you for comment. I agree that the lower level is more important, and safer to set the first target.

> Script shaping produces the real world test cases for OTL implementation, so helps us determine what needs to be tested and what kinds of behaviour need to be specified—beginning with how to do script itemisation and run segmentation correctly, and proceeding to things like tracking ordering of glyphs in which the glyph count is being altered multiple times by GSUB—but we need to be able to generalise the rules to apply at an abstract glyph processing level independent of specific scripts and languages.
> 
> The early years of OTL script specification and development were characterised by a focus on script-specific shaping, instead of generalisation. This is how we ended up with multiple registered OTL features that perform the same function, e.g. ccmp and akhn: the feature sets were specified as something particular to a class of scripts, instead of generalised at the level of glyph processing behaviour.

So, the documentation should be divided into 2 steps? Like, the first step is the generalized part, and the second step is the script-specific part - maybe, if there is an existing document for the generalized part and there are many same functionalities under different feature names, the documentation of the script-specific part could be slightly easier.

Regards,
mpsuzuki