[MPEG-OTSPEC] Many to many substitution and localization

[Laurence Penney]

William,

Your goal seems to be, essentially, to transform one short character sequence into a long character sequence, depending on local context. Nothing wrong with that, and it’s more or less how multilingual menus and error messages are handled in most software.

However your method transforms one *glyph* sequence into another *glyph* sequence, and would have the serious drawback that the text, when selected by the recipient, would still yield the original *characters* — something meaningless like "!313125". This prevents numerous benefits of receiving the correct *character* sequence, such as:
- the ability for users or system builders to change font;
- copy & paste;
- forwarding the message to someone else without the special font;
- text-to-speech;
- and so on.

Going back to your goal, character sequences should be manipulated outside of fonts, not within fonts. If you are designing a system for exchanging messages via short codes, you should:
a) embed the decoded messages on each sending and receiving device — in all languages that the recipient needs access to;
b) perform the encoding and decoding in regular code, not using OpenType substitution.

regards,

- Laurence

> On 26 Sep 2024, at 23:02, William_J_G Overington via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:
> 
> 
> Hin-Tak Leung replied.
>  
> Thank you for replying.
>  
> Hin-Tak Leung wrote as follows.
>  
> > You are almost asking for a a stripped down version of google translate to be built into the localisation features of opentype spec and implementations?
>  
> No, not at all.
>  
> By comparison, the OpenType specification specifies the liga table, but does not provide a list of ligatures to use. No list of the ligatures used by Gutenberg or any other printer is provided in the OpenType specification. The OpenType specification provides the liga glyph substitution facility: it is a matter for the font designer to decide which, if any, ligatures are to be included in a liga table in any particular font. There might not even be a liga table in some particular font.
>  
> So it would be with this present idea. If implemented in the OpenType specification then no codes or sentences would be specified in the OpenType specification.
>  
> The standardization of the codes will hopefully be by ISO/TC 37 and they have the slide show to which I linked as a United Kingdom contribution. There was a good chance that the slide show would be presented by a Member of the United Kingdom delegation at the ISO/TC 37 plenary meeting that was due to be held in June 2020, but the meeting did not take place due to the COVID-19 situation at that time.
>  
> The codes, such as !983 and !313125 are just my ideas that I have devised for my research project. If ISO/TC 37 standardizes a collection of localizable sentences then they can if they wish use the codes that I am using in my research, or they can devise codes of their own choosing if they so prefer.
>  
> If my idea that I have written about in this thread becomes implemented in the OpenType specification then which, if any, codes and into which language or languages they are localized in any particular font will be a matter for the font designer, not for the OpenType specification.
>  
> William Overington
>  
> Thursday 26 September 2024
>   _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec