Re: Treating IVS on SVG in OpenType

I wrote:
> Also: note that cmap subtable format 14 should not map sequences (b) or (c) above to anything other than x, since both UVSes are satisfied by the same glyph ID.

I didn't mean to imply there should be explicit UVS mappings to x in a cmap subtable format 14 at all. cmap subtable format 14 could be entirely absent in the font. A regular cmap subtable e.g. Microsoft Unicode BMP could map U+231A => x and that's all that's needed.

In a layout engine, the presence of the text style or emoji style variation selector in the input text could result in the resulting glyph ID being flagged as such. And then this flag would then be consulted when it comes time to render the glyph, to make the CFF-or-SVG decision.

Sairus


From: Sairus Patel <sppatel@adobe.com<mailto:sppatel@adobe.com>>
Date: Thursday, October 17, 2013 6:52 PM
To: onyx labo <onyxtechlabo@gmail.com<mailto:onyxtechlabo@gmail.com>>, "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>>
Subject: Re: Treating IVS on SVG in OpenType
Resent-From: "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>>
Resent-Date: Thursday, October 17, 2013 6:53 PM

Hi, onynx,

Thanks for bringing Unicode's "emoji style" variation selectors to our attention.

Using an example from http://www.unicode.org/Public/UCD/latest/ucd/StandardizedVariants.html:

a. U+231A = WATCH
b. U+231A U+FE0E = WATCH text style
c. U+231A U+FE0F = WATCH emoji style

Say for example the CFF glyph ID for U+231A WATCH in a font is x, and there is also an SVG glyph description for glyph ID x in the font.

Whether to render the CFF or the SVG description for x should depend on factors outside of the font, e.g.:
1. Whether the U+FE0E (text style => CFF) or U+FE0F (emoji style => SVG) variation selector is present in the text stream
2. And/or whether there is other style markup to indicate a similar distinction.

It should probably not be a part of the OpenType spec proper to mandate which should be used. (Also: note that cmap subtable format 14 should not map sequences (b) or (c) above to anything other than x, since both UVSes are satisfied by the same glyph ID.)

A similar issue is whether to render a particular SVG glyph description with animations enabled or disabled. This depends on factors outside of the font e.g.
i. Is animation possible for the context (e.g. printing to paper)
ii. Is animation feasible for the client at all (some apps' architectures may preclude animation completely)
iii. Whether there is style markup to indicate an animation preference, or a Unicode variation selector in the future.

Thus, the part of the SVG-in-OT spec's "Text Layout Process" section that says:

>  At this point, for each such glyph ID, if an SVG glyph description is available for it, it is rendered (in static or animated mode, as appropriate and if supported by the engine); otherwise, the CFF or TT glyph description must be rendered.

should probably be softened not to mandate a hard prioritization of "SVG first, then CFF/TT". And an explicit UVS example would be useful. I'll bring this up in subsequent iterations of the spec on the Open Font Format mailing list (mpeg-OTspec@yahoogroups.com<mailto:mpeg-OTspec@yahoogroups.com>).

Does this make sense? Please let us know what you decide in this regard for your project.

Sairus


From: onyx labo <onyxtechlabo@gmail.com<mailto:onyxtechlabo@gmail.com>>
Date: Thursday, October 10, 2013 2:20 PM
To: "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>>
Subject: Treating IVS on SVG in OpenType
Resent-From: "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>>
Resent-Date: Friday, October 11, 2013 6:11 AM


Hello,

This is onyx. I'm a coordinator of Japanese Emoji and has first  implemented it into the Android in Japan.

As you know, Japanese carriers have an original design for Emoji which is usually used in mail only and are used the gray scale font for other applications. However Unicode 6,0 defined a part of these Emoji are unified the original code which existed in Unicode 5.2. So we need to define to use either colorful or gray scale with easy implementation to fit each scene of applications.

And we have to decide this solution ASAP due to transfer the Unicode 6.0 Emoji data with Japanese carrier Email via internet.

My understanding is we can use the colorful or gray scale Emoji separately if we use this OpenType format. If we need to select the 2 color types data with each applications, I consider to use the IVS number to use this purpose. (& easy implementation)

However I couldn't find the descriptions to deal with the IVS number in this specification. My understanding is:
If IVS number is 0 or nothing, we draw the glyph with gray scale and draw the colorful Emoji in case of other number (ex. 1).
Is this correct??

Could you let me know your idea about this issue?? Or appropriate discussion groups??

onyx