[MPEG-OTSPEC] Shared GSUB/GPOS notes, was Re: dmap proposal

[Skef Iterum]

With this sort of deep and messy question it can be clarifying to 
consider how one /should/ address the answer in the specification.

If I understand you right, things have gone against the script/language 
mechanism over the past decades on the (broadly speaking) client side. 
So the responsible thing to do now would be to deprecate that mechanism 
in the spec and recommend that future fonts do all substitutions and 
positioning in the context of DFLT dflt. This will save foundries a lot 
of effort and heartache.

Analytically: if this is what should be said then we should say it.

What worries me about the dmap proposal /as a solution to the 
language/region problem/ is:

 1. Instead of saying the above outright, it sort of mumbles it in a way
    that will be picked up on by sophisticated readers, who will realize
    that constructing TTC slots with distinct (effective) cmaps, and
    then also trying to have all of those slots support every language
    via GSUB/GPOS, increases the development burden and multiplies the
    QA burden so that must not have been the intended goal.
 2. Because of 1, it creates a self-fulfilling prophecy of fewer and
    fewer fonts using the GSUB/GPOS mechanism leaving less and less of a
    reason for client-side implementations to use them fully and correctly.

Thus we consign the future to the present while hanging anyone who 
missed the message out to dry.

In contrast, a hinge point in GSUB/GPOS means that one can design a 
single unified font and just tie into the "initial" script/language 
using the overlapping GSUB trick (which could presumably be canned in a 
tool-set like fontTools) and TTC, addressing the messy present while not 
giving up on the better future.

Skef

On 12/27/23 08:55, John Hudson wrote:
> On 2023-12-27 3:19 am, Skef Iterum wrote:
>>
>> Some preliminary notes on an idea I'm looking info, starting from 
>> this line of reasoning:
>>
>>  1. My worry about using dmap for multi-language/region support is
>>     that the solution is separate from the script/language GSUB/GPOS
>>     mechanism. *Ideally we want fonts that support different scripts
>>     and languages via the latter*, and doing so while starting with
>>     different initial cmaps is a lot of work and QA.
>>
> *Do we? *The langsys mechanism in OTL has proven to be unreliable for 
> coming up on thirty years, such that we now recommend to clients 
> having separate fonts for individual languages if differences in glyph 
> shape or behaviour are considered critical. The chain of things that 
> document creators and software need to get right to ensure correct 
> display of langsys-specific GSUB or GPOS is too fragile to be 
> reliable, while selecting a clearly labeled font targeting a specific 
> language is much more robust. Hence, e.g. Tiro Devanagari Hindi, Tiro 
> Devanagari Marathi, and Tiro Devanagari Sanskrit.
>
> JH
>
>
> -- 
>
> John Hudson
> Tiro Typeworks Ltdwww.tiro.com
>
> Tiro Typeworks is physically located on islands
> in the Salish Sea, on the traditional territory
> of the Snuneymuxw and Penelakut First Nations.
>
> __________
>
> EMAIL HOUR
> In the interests of productivity, I am only dealing
> with email towards the end of the day, typically
> between 4PM and 5PM. If you need to contact me more
> urgently, please use other means.
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20231227/b4d3826d/attachment-0001.html>