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

[suzuki toshiya]

Dear 梁海,

> “Text layout” is a kinda legacy term that originated from European and CJK experts’ notion that there’s nothing much beyond cmap for inline shaping and thus the whole display process of digital texts can be summarized as “layout”, from lines to paragraphs.

Oh! I found that I was too lazy to catch up the latest terminology. Now I understand that the "text layout" is the legacy term assuming the simple scripts like (some) European and CJK, so its assumed coverage is the smaller than "text shaping". It's my big misunderstanding. Thank you very much for clarification.

> Instead of trying to define coverage of terms, it’s much more helpful to just talk about issues. Whoever interested in an issue should take it up.

Indeed. The coverage of the term is not the highest priority to me, at present. The coverage of the tasks is the highest priority. What I want to know was whether the issue raised by W3C is covered by the text shaping WG's scope. The answer is "covered" - right?

Regards,
mpsuzuki

On 2020/08/04 12:27, 梁海 Liang Hai wrote:
> 
> The de facto meaning of “text shaping” is basically giving digital texts (ie, text strings, typically encoded in Unicode) a visual form (shape), with whatever relevant additional information (language tagging, OTL feature switches…). It’s more about inline and plain text display. A typical example of text shaping is what the OpenType technology (cmap + OTL + …) and HarfBuzz does.
> 
> “Text layout” is a kinda legacy term that originated from European and CJK experts’ notion that there’s nothing much beyond cmap for inline shaping and thus the whole display process of digital texts can be summarized as “layout”, from lines to paragraphs. People dealing with complex scripts these days, however, tend to prefer the term “text shaping” when specifically referring to those inline transformation operations because they’re very complicated already and distinct from how rich text formats and lines and paragraphs are composed together.
> 
> Vertical layout (not only Japanese, and not only CJK) is sitting on the vague boundary. It’s been always considered a business more in the realm of line composition, however it’s becoming more and more clear it’s more complicated than that. For example, the boundaries between rotated and upright runs in vertical lines create a lot problems for correct text shaping.
> 
> Instead of trying to define coverage of terms, it’s much more helpful to just talk about issues. Whoever interested in an issue should take it up.
> 
> Best,
> 梁海 Liang Hai
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flianghai.github.io%2F&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C0683b10ad1794226c58908d838264e94%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C637321084458486079&sdata=Q8AcBU2F0EaLiRYLJAtWUsY5iCy0ybDV2IN14mBltao%3D&reserved=0
> 
>> On Aug 4, 2020, at 09:51, suzuki toshiya <mpsuzuki at hiroshima-u.ac.jp> wrote:
>>
>> Dear AHG Convenor,
>>
>> Maybe it's too late to ask such question, but please let me ask about the coverage of "Text Shaping". The first web page suggested by Google for "Text Shaping" is the document of harfbuzz library. I understand "Text Shaping" does the selection or extraction of the graphic data for an appropriate glyph, or grapheme, or ligature, or cluster by a specified single font instance, from the string of the coded character set. It does not assume the input is marked-up text like HTML.
>>
>> I guess, "Text Shaping" is a part of "Text Layout", but some of "Text Layout" might be out of the scope of "Text Shaping". For example, the vertical layout of Japanese text, like,
>>
>> On 2020/03/26 4:56, 'Levantovsky, Vladimir' vladimir.levantovsky at monotype.com [mpeg-OTspec] wrote:
>>> 3.       Compatibility problem with ‘vert’
>>> The discussion linked from https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fwww-archive%2F2019Dec%2F&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C0683b10ad1794226c58908d838264e94%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C637321084458496070&sdata=geLIUtMe71wwfDDQkPQUCynAIN55%2BDJOD0eInAirO%2B8%3D&reserved=0<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fwww-archive%2F2019Dec%2F&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C0683b10ad1794226c58908d838264e94%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C637321084458496070&sdata=geLIUtMe71wwfDDQkPQUCynAIN55%2BDJOD0eInAirO%2B8%3D&reserved=0> seem to be specific to a particular behavior of existing version of Adobe InDesign application and Adobe Japanese font set. Considering the recent changes introduced by ISO/IEC 14496-22:2019/AMD1, I am not sure how much more (if anything) need to be done on the spec side. I do realize that both applications and fonts need to be updated to be compliant with new feature descriptions.
>>
>> is covered by "Text Shaping" ? I believe, "Text Layout" covers it, but I'm not sure whether "Text Shaping" covers it.
>>
>> Regards,
>> mpsuzuki
>>
>> _______________________________________________
>> mpeg-otspec mailing list
>> mpeg-otspec at lists.aau.at
>> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C0683b10ad1794226c58908d838264e94%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C637321084458496070&sdata=Yz9LNdbveHMbKzWGd%2F6bdVpxIQp8a8nqqEaumOBxt8c%3D&reserved=0
> 
>