Generating tool of SVG in OpenType

Hi, Sairus and all.

Can I have a generating tool of this font format?? And distribute it for
free??

I'd like to create an original designed emoji font set. (ex. cute, cool or
sharp) I have SVG data and code mapping table. However I can't find a tool
to generate it easily.

I understand this specification is open license, so everyone can create and
distribute.

onyx
2013/10/18 11:09 "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