Re: Treating IVS on SVG in OpenType

Hi Sairus,

Thanks for the detailed explanation.Your attention is satisfied with my
suggestion.

I know the color (or animated) Emoji can be shown or not is depending on
the render. However I might recommend to describe this attention (using
U+FE0E or U+FE0F) in this SVG-in-OT specification. Since the email with
Emoji are using with another character code now in Japan and planning to
change to Unicode 6.2 based in the near future I think. If another
specification will be officially adopted in Japan, it's too difficult to
change to this attention.

And could you let me know if the information is updated on the Open Font
Format mailing list?? (mpeg-OTspec@yahoogroups.com)

Onyx


2013/10/18 Sairus Patel <sppatel@adobe.com>

> 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>
> Date: Thursday, October 17, 2013 6:52 PM
> To: onyx labo <onyxtechlabo@gmail.com>, "public-svgopentype@w3.org" <
> public-svgopentype@w3.org>
> Subject: Re: Treating IVS on SVG in OpenType
> Resent-From: "public-svgopentype@w3.org" <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).
>
> Does this make sense? Please let us know what you decide in this regard
> for your project.
>
> Sairus
>
>
> From: onyx labo <onyxtechlabo@gmail.com>
> Date: Thursday, October 10, 2013 2:20 PM
> To: "public-svgopentype@w3.org" <public-svgopentype@w3.org>
> Subject: Treating IVS on SVG in OpenType
> Resent-From: "public-svgopentype@w3.org" <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
>