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

[梁海 Liang Hai]

> I must thank for your huge effort for UTN#11. At the same time, I'm afraid that it's really hard task to create such documents as a part of ISO spec (UTN#11 is 67 pages!). Especially for some historic or minority scripts which SIL is working for. Also Liang Hai is working with "Text representation and shaping specification of the Mongolian script" which is assumed to be one of the Unicode Technical Notes. Either I think it's not easy for ISO/IEC 14496-22 to include such documents as the appendix.


Part of the reason why I’m not keen on organizing this collective effort under ISO’s management (be it a WG, Ad Hoc Group, or what), is that ISO and/or JTC1’s publication process is not suitable for the documents we’re thinking. All we need is an easy to navigate modern website with all the vital information we want to maintain, but I doubt ISO/IEC ITTF will grant us that. To be honest, it’s a pain to read those procedural documents in JTC1’s official format—it’s just gonna discourage potential participants for no good reason.

It may be nice and valuable though, to periodically have a subset of our outcome be rubber-stamped by JTC1, like how a subset of the Unicode Standard is published as ISO/IEC 10646 with a lower frequency. I guess this subset will just largely have the same scope of the current OFF.

Best,
梁海 Liang Hai
https://lianghai.github.io

> On Aug 4, 2020, at 09:26, suzuki toshiya <mpsuzuki at hiroshima-u.ac.jp> wrote:
> 
> 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
> 
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec