Philippe Verdy wrote:
> What you are describing is reinventing the wheel, notably basically what SVG
> paths already define.
Well, I am trying to express, within a tag sequence that could be included in
an interoperable Unicode plain text message, the glyph information for one
emoji glyph of an OpenType colour font.
I have not included anything about SVG.
> Font encoding technologies define their own system using multiple tables and
> a compact dictionnary of tables with binary encoding, not suitable for
> inclusion in plain-text.
Yes, that is why I have devised this format, so that the glyph information for
one emoji glyph of an OpenType colour font could be included in a Unicode plain
text message.
> Note also that Emojis could be animated when rendered on screen (that's what
> we already see in many implementations using GIF icons for their emojis, even
> if they are not easily resizable). Animated SVG for now is still in beta but
> starts being used on some sites and rendered by web browsers. SVG images may
> also be scripted and may include accessbility feature (e.g. with sound played
> or hint bubbles displayed when hovering them).
The format that I suggested could be extended if desired.
For example, h is for an unanimated glyph.
There could be added q and e if desired, so that instead of h one uses q for
completing the glyph for each frame, and then e to export the complete animated
glyph.
For example, as follows.
q means {define a complete glyph of advance width w from the glyph or glyphs in
the glyphs buffer and place it in the animation buffer; reset everything except
the animation buffer ready to define the next glyph in the animation;}
e means {produce an animated glyph from the contents of the animation buffer
ready for access by the main program; halt;}
Yes, accessibility features are important and I will try to think about
including them. Readers are welcome to make suggestions as to what is needed.
> You only cover a part of what is needed ....
Well, yes, I suppose so, yet what I have published could get something started
and anything else that is needed could be added, either by me or by the Unicode
Technical Committee and the Emoji Subcommittee if people are interested in
implementing the idea.
> .... but hope that someone will invest time to implet it in a renderer:
Well, yes eventually.
I am hoping that the idea will be discussed in the mailing list and then go
forward to the Emoji Subcommittee and then go to the Unicode Technical
Committee and then become part of The Unicode Standard and then be used by
people.
Many people think of new encoding ideas and put them forward to the Unicode
Technical Committee, sometimes starting with a post in this mailing list before
a formal submission in the hope that the discussion will be helpful. Such
discussion often improves the formal submission. That is the process, the way
that Unicode progresses.
> ... developers prefer investing time in SVG renderers or existing font
> technologies for OpenType (SVG fonts will come later when it will be capable
> of doing the same things as OpenType, for now it does not cover all the
> existing needs).
Well, I do not know what developers prefer. There seems to be a need to send
custom emoji in interoperable Unicode plain text and I have put forward an idea
for how to do it.
William Overington
Tuesday 4 April 2017
