Re: Generating tool of SVG in OpenType

Hello onyx;

Sairus Patel forwarded your message to me.

I did write some scripts that allow getting from SVG documents to an SVG table in an OpenType font. These all require the Python interpreter.  They also require the open-source tool 'ttx',  which compiles/decompiles between an OpenType font file, and an XML representation of the same.

I do NOT have scripts to make a separate color table. My examples had the colors hard-coded in the <svg> elements.

The easiest way to get the ttx and associated scripts tool in a useful form is to download and install  the AFDKO font tools from Adobe, at:
  http://www.adobe.com/devnet/opentype/afdko.html

You can, alternatively,  get 'ttx' from:
   https://github.com/behdad/fonttools

Given set of massaged SVG documents , the workflow is as follows:

1) Pick an OpenType font to which you want to add the SVG table.

2) Create a set of SVG docs to add to a new SVG table for the font. Put them in any directory. I will assume for the following examples that they are in the directory 'svgDocs'. The file names for the SVG docs must start with a common prefix ( in these examples I will use "gid"), and follow the format:
"<file prefix>.start GID>.<end GID>.svg"

Example svg doc file name, with the prefix 'gid':
gid.2.2.svg

'GID' is short for Glyph ID, which is the index number of a specific glyph in the list of glyphs in a font. You can dump the current font glyph ID list with the ADKO tool' tx':
 tx  –dump –4 myFont.otf

(note that  'tx' is a very different tool than ttx)

The SVG glyphs can have GID's that are not in the list of font glyphs, and can overlap with the list of font glyph GIDs. . If an SVG glyph has the same GID as a font glyph, than an SVG-table aware rendering system will show the SVG glyph instead of the  font glyph.

2) Dump only one small table from the OTF, in order to get a ttx XML file to which the SVG table definition can be added.
ttx  –t head myFontFile.otf
#  creates  myFontFile.ttx, containing an XML definition of the 'head' table.

3) Run the AFDKO script 'importSVGDocsToSVGTable.py' to copy the SVG docs into an XML definition of the SVG table and add  it to the 'ttx' file.
AFDKOPython  FDK/Tools/SharedData/FDKScripts/importSVGDocsToSVGTable.py myFontFile.ttx   svgDocs  gid

4) run 'ttx' to merge the table definitions from the TTX output file back into the font
ttx -m myFontFile.otf   myFontFile.ttx


The SVG docs must be created such that they work well with the other glyphs in the file:
The graphics for each glyph must be contained in an <svg> element
A source SVG file may contain more than one <svg> element
The inclusive range of  startGID to endGID in the file name must match the number of SVG elements in the file
The svg  graphics must be sized and positioned to work well with the design of the font's glyph
If the svg glyph is an alternate of an existing glyph in the font, the width, size, and position should match the font glyph.

When exporting artwork from Illustrator. I found that I  had to manually remove comment headers. It was also useful to simplify the SVG: Illustrator adds a lot of stuff like clipping paths, which are not useful in the SVG table.


The FDK contains its own Python interpreter, invoked with the command AFDKOPython. Compiling and decompiling the SVG table with 'ttx' is handled by a module file which is at:
FDK/Tools/osx/Python/AFDKOPython27/lib/python2.7/site-packages/FontTools/fontTools/ttLib/tables/S_V_G_.py

Hope this helps,
 Read Roberts


From: Sairus Patel <sppatel@adobe.com<mailto:sppatel@adobe.com>>
Date: Friday, December 6, 2013 9:33 AM
To: David Lemon <lemon@adobe.com<mailto:lemon@adobe.com>>, Caleb Belohlavek <cbelohla@adobe.com<mailto:cbelohla@adobe.com>>, Read Roberts <rroberts@adobe.com<mailto:rroberts@adobe.com>>
Cc: Ken Lunde <lunde@adobe.com<mailto:lunde@adobe.com>>, Taro Yamamoto <tyamamot@adobe.com<mailto:tyamamot@adobe.com>>, Azita Mostafavi <azitam@adobe.com<mailto:azitam@adobe.com>>
Subject: FW: Generating tool of SVG in OpenType

Caleb, David, Read,

Onyx (who described him/herself as "a coordinator of Japanese Emoji and has first  implemented it into the Android in Japan") is asking about tooling to make an SVG-in-OT emoji font. I know Read was able to generate a couple of test fonts.

Would you be able to help onyx with the tooling aspect of his/her project? I think this would involve starting with responding to onyx's email on the thread below, including cc'ing public-svgopentype@w3.org<mailto:public-svgopentype@w3.org> (you don't have to be a member, and there are only about a dozen folks on it). No fully integrated end-to-end tools would be expected, just a rough description of your process, perhaps with ttx as the final "compiler" of the SVG files.

If you prefer, you can compose an email response and I'll sent it out, cc'ing you.

Thanks,
Sairus

From: onyx labo <onyxtechlabo@gmail.com<mailto:onyxtechlabo@gmail.com>>
Date: Friday, December 6, 2013 1:17 AM
To: Sairus Patel <sppatel@adobe.com<mailto:sppatel@adobe.com>>
Cc: "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>>
Subject: 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<mailto: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<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