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

[Martin Hosken]

Dear All,

In terms of what we document, I suggest that there are a number of prongs to the fork. Here is my take on the list:

1. Technology Documentation
Describes the underlying technologies script implementations rely on. For example, OpenType, shaping engines.

2. Orthographic Information
This describes the encoding of a particular orthography (or group of orthographies) along with any community expectations regarding styling, behaviour, etc. But it is implementation independent. UTN#11 tries to do this for orthographies using the Myanmar script, as an example.

3. Design Considerations
Typographical design considerations across groups of orthographies. May or may not include user experience expectations.

4. Engineering Implementation Description
Describes behavioural implementation details of particular implementations for particular orthographies.

I suggest that people will tend to gravitate towards one, or maybe two of these categories. And that is fine. This is not a one person game. I also think that funders may also gravitate similarly.

To me, categories 1 & 2 are foundational and are aiming at normative descriptions. Categories 3 & 4 are also vital to grow the pot of quality font implementations these communities so desperately need.

The emphasis on orthography here is evident. I hold that the orthography is the primary minimal unit of implementation. Many orthographies have similar needs. But they also have uniquenesses. We need to capture all of that so that implementers can choose the range of orthographies they intentionally or unintentionally will support.

Yours,
Martin

> In terms of defining scope, I would employ a broad view of typographic 
> text display. There are intersections and mutual dependencies to be 
> mapped with text encoding and text interaction (input and editing), but 
> I think a natural scope can be defined in terms of the space where font 
> interaction is necessary to achieve overall layout and display of text, 
> i.e. everywhere from script segmentation to justification.
> 
> That's the scope I suggested in looking 'beyond shaping' in my IUC39 
> presentation:
> http://tiro.com/John/Hudson_IUC39_Beyond_Shaping.pdf
> To the aspects discussed there, I would add text block orientation, i.e. 
> layout directionality as distinct from character and string directionality.
> 
> JH
> 
> > Thank you Liang and Simon for starting the discussion!
> >
> > Since we are going to embark on the exploration activity to determine 
> > the scope of this future work, it is extremely important to identify 
> > what relevant information is currently missing [that affects 
> > interoperability of fonts and implementations] and if it needs to be 
> > specified as a formal standard. It is also important to determine who 
> > currently possesses the relevant knowledge and experience, and is 
> > willing to contribute to this important work.
> >
> > I also agree with you that it is very valuable to identify all related 
> > documentation, but we also need to be aware of its current status 
> > (public / opensource / proprietary / copyrights, etc.) Knowing what we 
> > have as a starting point (such as e.g. USE document: 
> > https://docs.microsoft.com/en-us/typography/script-development/useand 
> > all other resources Liang has mentioned) and whether any existing / 
> > prior documentation could be contributed for us to use will not only 
> > give us a head start, but also helps come quickly to a decision on 
> > whether we need to consider publishing formal script-specific text 
> > layout specifications, or if it may be more appropriate to publish it 
> > as OFF/OpenType implementation guidelines, or both.
> >
> > All these components – the information about what we have to start 
> > with, who can contribute to this development [and whether they are 
> > willing to do so], and what we believe the outcome of this work should 
> > be – will help us greatly to decide what organization (Unicode 
> > Consortium and this ISO WG were initially named for consideration) 
> > would be best suitable to be selected as the venue for this future work.
> >
> > Thank you,
> >
> > Vladimir
> >
> > *From:*mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> *On Behalf Of 
> > *?? Liang Hai
> > *Sent:* Wednesday, July 29, 2020 10:35 AM
> > *To:* mpeg-otspec at lists.aau.at
> > *Subject:* [MPEG-OTSPEC] Defining the text shaping working group’s scope
> >
> > (If this topic confuses you, see the appended background introduction.)
> >
> > In order to figure out the scope we care about, how about we start 
> > with maintaining a list of existing projects that are intended to 
> > complement the OT spec (and its semi-standard specs such as the USE spec)?
> >
> > In terms of my personal concerns, one of the most important projects 
> > today is this documentation by Nate Willis, et al, which is focused on 
> > documenting how OTL should actually be implemented for each complex 
> > script, so developers can actually implement compatible shapers:
> >
> >     *Documentation of OpenType shaping behavior*
> >
> >     https://github.com/n8willis/opentype-shaping-documents
> >     <https://protect-us.mimecast.com/s/QFjcClYmL2U2KB9mIGIQRV>
> >
> > On the other hand, my main personal interest is about clarifying how 
> > Unicode encoded complex scripts (especially the Indic ones) should be 
> > implemented with OTL fonts. (Note the difference from Nate’s project, 
> > which is about how to shape texts using these fonts.)
> >
> > I believe we need to document a reference interface between 
> > orthographical correctness and typographical concerns. The whole 
> > process from Unicode text up to this interface can be vetted by 
> > experts (especially for compatibility and reasonable fallback 
> > behavior) and automated by tooling, while font producers are left with 
> > a straightforward glyph set to fill. This will greatly improve 
> > reliability of complex scripts’ fonts, and also remove the 
> > unreasonable obstacle that prevents native users to implement their 
> > own scripts in fonts. Some knowledge collected during this effort 
> > should even be incorporated into the Unicode Standard, if it’s 
> > relevant and the community can achieve an agreement on it.
> >
> > The current early draft is still very sketchy, but I expect to 
> > significantly update it and transform it into a tutorial-based 
> > document (because concrete instructions will be much easier to read) 
> > in a couple of months:
> >
> >     *Indic text shaping for type designers*
> >
> >     https://github.com/typotheque/text-shaping
> >     <https://protect-us.mimecast.com/s/_XWACmZn6YIjYm08HOyLHI>
> >
> >
> > Best,
> > 梁海Liang Hai
> > https://lianghai.github.io 
> > <https://protect-us.mimecast.com/s/UOpPCn5oXgs7LJygUNFAcv>
> >
> > ---
> >
> > Some context for subscribers of this mailing list who didn’t 
> > participate in yesterday’s meeting:
> >
> > There’s a collective effort to seek a clear path forward for improving 
> > the whole text shaping industry (including the font formats)’s 
> > situation. Yesterday there was the first meeting, and the next meeting 
> > (open to all) is scheduled for four weeks later (25 Aug, 13:30–14:50 
> > UTC-4). The following document contains yesterday’s meeting notes:
> >
> >     Text Shaping Working Group (working title)
> >
> >     https://docs.google.com/document/d/1KoknOb0IMAPeiLhifvc_AqB7s3rs6VKOsTQg_oCDypQ/edit?usp=sharing
> >     <https://protect-us.mimecast.com/s/813pCo20KjhrG7o5c6dpOk>
> >
> > By the end of the meeting we decided this list could be a temporary 
> > home for our discussions because of the significant overlap of 
> > interest. I hope we’re /not/ spamming you guys.
> >
> >
> > _______________________________________________
> > mpeg-otspec mailing list
> > mpeg-otspec at lists.aau.at
> > https://lists.aau.at/mailman/listinfo/mpeg-otspec  
> 
> 
> -- 
> 
> John Hudson
> Tiro Typeworks Ltd    www.tiro.com
> Salish Sea, BC        tiro at tiro.com
> 
> NOTE: In the interests of productivity, I am currently
> dealing with email on only two days per week, usually
> Monday and Thursday unless this schedule is disrupted
> by travel. If you need to contact me urgently, please
> use some other method of communication. Thank you.
>