Re: Generating tool of SVG in OpenType

Hi, Robert

Thanks for the detailed explanation.

I'm going to try it and may have some questions if necessary.

Best regards,
onyx
2013/12/07 7:44 "Read Roberts" <rroberts@adobe.com>:

> 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>
> Date: Friday, December 6, 2013 9:33 AM
> To: David Lemon <lemon@adobe.com>, Caleb Belohlavek <cbelohla@adobe.com>,
> Read Roberts <rroberts@adobe.com>
> Cc: Ken Lunde <lunde@adobe.com>, Taro Yamamoto <tyamamot@adobe.com>,
> Azita Mostafavi <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 (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>
> Date: Friday, December 6, 2013 1:17 AM
> To: Sairus Patel <sppatel@adobe.com>
> Cc: "public-svgopentype@w3.org" <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>:
>
> 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
>
>