Tags and custom vector glyph emoji (from Re: Tailoring the Marketplace (is: Re: Unicode Emoji 5.0 characters now final))

William_J_G Overington wjgo_10009 at btinternet.com
Tue Apr 4 05:18:36 CDT 2017


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



More information about the Unicode mailing list