[MPEG-OTSPEC] [EXTERNAL] Re: New AHG mandates and other news!
William_J_G Overington
wjgo_10009 at btinternet.com
Tue May 11 20:12:01 CEST 2021
> Your original idea of localizable sentences, as I recall, involved
> assigning Unicode code points to particular semantic propositions, or
> “sentences”.
Yes, that was the original idea, back in 2009.
Research has continued and developed. There are several possible
encodings in the research, all involve sequences: two are markup, one
involves the exclamation mark and ordinary digits, the other involves an
integral sign and circled digits - harder to write a message, but more
robust.
The third possible encoding needs a regular Unicode/ ISO-IEC 10646
encoding but would be unambiguous, highly robust and clearly free of
concerns about proprietary rights. Yet it needs agreement from Unicode
Inc. and ISO/IEC 10646 committees.
> Unicode has stated clearly it is not interested in pursuing that idea
> and banned further discussion of that idea from its email lists.
Actually no. A fictional character with email address root at unicode.org
banned discussion. It was not a statement by an official named officer
of Unicode Inc. acting officially. So its validity is highly
questionable. If Unicode Inc. wishes to ban discussion of localizable
sentence technology then it could officially state that, but Unicode
Inc. has not done that. No notice of disapproval for encoding
localizable sentences has been made.
Rather, the banning by a fictional character is like a Unicode version
of The Luxembourg Compromise.
The fictional character did not state any reason why localizable
sentences are unsuitable for encoding.
https://en.wikipedia.org/wiki/Luxembourg_compromise
I have not been given a fair opportunity to state my case and have it
debated.
QID emoji has been treated as a serious proposal and a Public Review has
taken place.
My proposal for localizable sentences being encoded is far more robust,
and, I opine, should be treated seriously and assessed properly on a
"sauce for pasta is sauce for rice" basis.
So there is nothing OFFICIAL about localizable sentences from Unicode
Inc. of which I am aware.
So I keep trying to get my proposal for localizable sentences considered
by Unicode Inc..
> I don’t think you should be trying to use this list as a back door to
> revisit the same idea.
I am not using this list as a back door. There has been a call for ideas
and I have put one forward. From what you now write it appears that the
'name' table will not do what I am proposing in what, for purposes of
discussion, can be called the 'text' table, because, as far as I am
aware, that name is not already in use for an OpenType table.
Also, I am entitled to try to get my invention implemented.
So I am in favour of having the 'text' table and Peter is not, so that
is 1 vote for and 1 vote against at this time.
So the proposal goes forward and hopefully other people will express a
view and a consensus will emerge.
> Again, there’s an unstated premise of this idea that the font will get
> transported with the message.
No, there is no such premise.
There is as far as I am aware no premise or presumption when sending any
email message that a font will get transported with the message.
My idea is that the message list will be an international standard and
that localization will take place automatically in the receiving device
when a language-independent encoded message is received, using a
decoding list local to the recipient.
I have recently decided that all localizable sentences that are encoded
shall have a language-independent glyph - at one time I considered that
glyphs were not always needed, but I have since changed my mind on this
as my research has proceeded.
I have replied to the comments made. The 'text' table would have far
wider application that just localizable sentences.
William Overington
Tuesday 11 May 2021
.
>
------ Original Message ------
From: "Peter Constable" <pconstable at microsoft.com>
To: "William_J_G Overington" <wjgo_10009 at btinternet.com>; "'MPEG OT Spec
list'" <mpeg-otspec at lists.aau.at>; "Peter Constable" <pgcon6 at msn.com>;
"Vladimir Levantovsky" <vladimir.levantovsky at gmail.com>
Sent: Tuesday, 2021 May 11 At 17:50
Subject: Re: [EXTERNAL] Re: [MPEG-OTSPEC] New AHG mandates and other
news!
The ‘name’ table stores strings for various purposes. Some of these
purposes are pre-defined in the spec; some examples:
* a family name such as “Arial”
* a subfamily name such as “Condensed Bold Italic”
* a foundry name
* a copyright string
But the format also allows for other strings for vendor-defined
purposes. So, for instance, in variable fonts, the vendor can define
instances (particular design variants) for some combination of variation
axis values, and then they can define what would effectively be
subfamily names for those specific instances.
The actual strings themselves are indexed with a two-part key that
includes an ID (generally referred to as the “name ID”), which indicates
the purpose (as described above), and a numeric language identifier.
So, using vendor-specific name IDs and language IDs, you could add the
kind of strings you describe into a font’s name table.
But there isn’t any existing way to associate particular glyph sequences
with a name ID. And that is the part that, in general, doesn’t have a
clear need in the way that fonts are used.
Your original idea of localizable sentences, as I recall, involved
assigning Unicode code points to particular semantic propositions, or
“sentences”. Unicode has stated clearly it is not interested in pursuing
that idea and banned further discussion of that idea from its email
lists. I don’t think you should be trying to use this list as a back
door to revisit the same idea.
Now, what you’ve described seems to have evolved from that original
idea—though only slightly: now you’re talking about glyph sequences that
represent “sentences”. Based on your slide presentation, it appears you
want a message containing “!313125” to get associated with a string “Is
there any information about the following person please?” (along with
other translations), and you want to use a font table to provide a
mapping from the glyphs for the character sequence “!313125” to that
string (in its various translation variants). Again, there’s an
unstated premise of this idea that the font will get transported with
the message. If it did, the font would have some fixed sent of
translations. Why not just send a message with multiple translations?
Or why not create an online registry that documents the sentences and
translations in many languages, and then send as a message a URL that
points to the registry entry for “!313125”?
For my part, I don’t see a need to add into the OpenType / OFF spec a
table that provides a mapping from glyph sequences to name IDs.
Peter
From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> on behalf of
William_J_G Overington <wjgo_10009 at btinternet.com>
Date: Tuesday, May 11, 2021 at 4:21 AM
To: 'MPEG OT Spec list' <mpeg-otspec at lists.aau.at>, Peter Constable
<pgcon6 at msn.com>, Vladimir Levantovsky <vladimir.levantovsky at gmail.com>
Subject: [EXTERNAL] Re: [MPEG-OTSPEC] New AHG mandates and other news!
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMPEGGroup%2FOpenFontFormat&data=04%7C01%7Cpconstable%40microsoft.com%7Cfe51c13919584abc23dd08d9146ec3d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637563288688874579%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Slzh2fSOikrSWx%2F0HhjBIhycZjbUfbMoSWvUkFQ22xA%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/707c3169/attachment-0001.html>
More information about the mpeg-otspec
mailing list