[MPEG-OTSPEC] Many to many substitution and localization

Hin-Tak Leung htl10 at users.sourceforge.net
Thu Sep 26 19:48:13 CEST 2024


 That isn't quite the response I was expecting from one of the "inplementers".

Anyway, I would give my answer, ask one question and give one example.

My short answer is, "yes, but why / do you have to?"

The one question would be: is there any genuine many to many substitution which is not expressible in a combination of chaining many-to-one (?characters to glyphs) and one-to-many (?glyph to subglyph) rules?

The one example would be arabic / Islamic honorific lignatures. They are literally entire sentences/ clauses, which are mapped from multiple characters and in turn rendered in multiple subglyphs in the typical arabic fonts, as a whole visual unit.

And the longer answer would be, it is already possible in most practically useful scenarios, without adding anything new to the current spec or the current implementations.

     On Thursday 26 September 2024 at 18:12:39 BST, Simon Cozens via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:  
 
 On 26/09/2024 18:04, William_J_G Overington via mpeg-otspec wrote:
> Can this idea become implemented please?

The short answer is no.

Suppose a many-to-many substitution is implemented with the lookupflag 
of "IgnoreMarks", and suppose also that there are marks in the input 
glyph sequence. It's not possible to determine how those marks should be 
distributed amongst the new set of glyphs produced by the substitution.

It's possible to do what you're asking for by first ligating glyphs into 
a single glyph ("sub exclam nine eight three by word_983") and then 
using a multiple substitution to perform the localisation ("sub word_983 
by D i o l c h ...") (Of course, the fact that you can do it does not 
mean you should.) So in practice, many-to-many substitution is often 
unneeded.


S
_______________________________________________
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/20240926/89def4ed/attachment.htm>


More information about the mpeg-otspec mailing list