[MPEG-OTSPEC] New AHG mandates and other news!

Tue May 11 12:50:12 CEST 2021

Thank you for replying.

I write to seek clarification please.

> You’ve described a way to organize data, but to get the functionality 
> you described the data would be organized differently: a table that 
> maps glyph ID sequences to string entries in the ‘name’ table.
I have found the following web page.

https://docs.microsoft.com/en-us/typography/opentype/spec/name

I am not an expert on OpenType, so as Peter mentions the 'name' table, 
is the implication that what I am suggesting is already implemented?

If not, can I suggest that for this discussion that we refer to my 
suggestion as a proposal for a 'text' table please?

I mention that use with QID emoji was just one suggested possibility and 
that there would be a number of other uses, even if QID emoji is never 
implemented. The use with QID emoji is not a central application 
suggestion for this proposed facility.

> It seems to me like you’re trying to propose enhancements the font 
> format to address challenges for the QID emoji proposal.

No. My suggestion has various possible applications, many related to 
communication through the language barrier. QID emoji were not my idea, 
I have expressed my views about the idea in my responses to the Unicode 
Technical Committee's Public Review.

https://www.unicode.org/review/pri408/

My own research is mostly on localizable sentences and their 
applications, together with some research on The Mariposa System of 
abstract emoji for assisting communication through the language barrier 
when using emoji.

Although emoji are interesting, from my perspective they do not have 
anything like the great potential for communication through the language 
barrier as does the localizable sentence invention. In particular, many 
pictorial emoji proposals tend to be deliberately imprecise as regards 
meaning and implied meaning of an emoji, yet localizable sentences 
characters are very deliberately precise as to meaning so as to provide 
high provenance as to meaning in communication through the language 
barrier.

http://www.users.globalnet.co.uk/~ngo/

In particular, the following slide show was produced for the United 
Kingdom National Body to forward to the ISO/TC 37 committee.

http://www.users.globalnet.co.uk/~ngo/slide_show_about_localizable_sentences.pdf

For some recent glyph designs for The Mariposa System, please see page 5 
of the following thread, starting with the fourth post on that page.

https://forum.affinity.serif.com/index.php?/topic/138654-artwork-for-greetings-cards/

Some readers might perhaps like the designs for some localizable 
sentence glyphs that are near the start of the thread.

William Overington

Tuesday 11 May 2021

------ Original Message ------
From: "Peter Constable" <pgcon6 at msn.com>
To: "William_J_G Overington" <wjgo_10009 at btinternet.com>; "'MPEG OT Spec 
list'" <mpeg-otspec at lists.aau.at>; "Vladimir Levantovsky" 
<vladimir.levantovsky at gmail.com>
Sent: Monday, 2021 May 10 At 22:58
Subject: RE: [MPEG-OTSPEC] New AHG mandates and other news!

William,

You’ve described a way to organize data, but to get the functionality 
you described the data would be organized differently: a table that maps 
glyph ID sequences to string entries in the ‘name’ table.

But the scenario you have in mind is to use fonts as a way to carry 
descriptions of Unicode character sequences, and specifically QID emoji 
sequences—which is an idea that has been proposed but has not been 
approved by Unicode. Even  _if_ the QID emoji proposal were adopted by 
Unicode—and it’s far from clear that it will be—, I don’t think it’s a 
good idea to use fonts as a vehicle for transporting descriptions of 
glyph ID sequences.

    * For the QID emoji sequence scenario, Unicode strings in general 
are sent between applications or between devices 99.99% of the time 
without any font data. So, it’s very unclear that  it would provide much 
useful benefit for that scenario.
    * If it is assumed that text containing QID emoji sequences would 
_need_ font data to be sent along with the text, then that raises a 
question of whether the QID proposal provides  significant benefit over 
using PUA characters.
    * The formats added to the font would not be inherently specific to 
QID sequences—that is, the design suggests a much more general usage: 
strings describing arbitrary glyph sequences.  But I don’t see any real 
need for such a general mechanism.

It seems to me like you’re trying to propose enhancements the font 
format to address challenges for the QID emoji proposal. For my part, I 
don’t think it’s a good idea. Fonts are not the best way to solve those 
problems. If Unicode is going  to consider the QID proposal, then 
proponents of the proposal need to come up with better ways to address 
any shortcomings in the proposal.

Peter

From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at>  On Behalf Of 
William_J_G Overington
  Sent: May 6, 2021 8:34 AM
  To: 'MPEG OT Spec list' <mpeg-otspec at lists.aau.at>; Vladimir 
Levantovsky <vladimir.levantovsky at gmail.com>
  Subject: Re: [MPEG-OTSPEC] New AHG mandates and other news!

> As part of the mandate #2, we are also encouraged to start exploration 
> activities to discuss the next round of changes that will become the 
> basis for the new OFF 5th edition work item – your contributions to 
> these topics (both  on this list and / or new issues on 
> MPEGGroup/OpenFontFormat GitHub 
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMPEGGroup%2FOpenFontFormat&data=04%7C01%7C%7C7e6370fe735f49ebb32408d910a4578a%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637559120296755956%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=igXd5Lph96xICJc8mh2u4eFDZnUvgtZ2ok%2Ft9ebxgdw%3D&reserved=0> 
> ) are much appreciated.

Would it be good to have a new table which is similar in structure to a 
GSUB table but which can have in the part to the left of each -> either 
one postscript name or a sequence of postscript names and to the right 
of each -> a string of Unicode text characters  in UTF-16 format - that 
is, a string of text characters as one might have in, say, a computer 
program written in Pascal, for the avoidance of doubt specifically not a 
sequence of postscript names.

I am thinking that this could have various uses, for example, for text 
to speech in a language of the font designer's choice, transliteration, 
on-screen explanation of emoji - including perhaps the potentially 
millions of QID emoji that may soon become encoded  into Unicode, so 
that a font that supports just a few QID emoji could also include an 
explanation of them in a language of the font designer's choice. The 
output of the table could be used for any of screen display, tooltip 
display, speech output. The use  of the table in a font would be 
optional and could be simply ignored by an application that does not 
support it: also an application that does support the use of the 
information that is in the table could have a button to switch that use 
on or off.

William Overington

Thursday 6 May 2021

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20210511/e117e8e5/attachment-0001.html>