Build color fonts

[brawer]

It would be nice if fontmake could build color fonts.

Glyphs already supports color fonts, both as vectors and images. Therefore, a glyphs file should contain all information needed to build color fonts in various formats.

Sadly, color font formats are very fragmented. As a general tool chain, I think fontmake should be agnostic about formats and try to support them all. (Of course, it would be nice if the industry could converge eventually). As an intermediate format, SVG might work because it can be easily converted into PDF, PNG, and JPEG images. Later in the pipeline, those images can then be packaged into sbix, CBDT, COLR, CBDT/CBLC, and similar tables depending on what format was requested.

[behdad]

We should support them all, yes. Easiest to make MS-style fonts from vector only, and Google & Apple style fonts from bitmap only. SVG can be made from both, and would be really cool indeed if we did.

[anthrotype]

one step towards this is extending UFO to allow linking a GLIF to an SVG file.
I suggested extending the <image> element in GLIF to allow linking to an SVG file in addition to PNG: unified-font-object/ufo-spec#104

[anthrotype]

Here's what I think is needed to allow building color fonts with fontmake.

We need a fontTools.colorLib that has functions to create the various OT color tables from input consisting of simple data types and collections: fonttools/fonttools#1222
colorLib can also have a converter module for translating from one color format to another.
Ufo2ft will use this to generate color font tables to be inserted into the main OTF.

Initially for simplicity we should support specifying glyph images as either vector graphics (SVG) or as bitmap (PNG), but not both (we may revise this later). The PNG sources can be used to generate sbix, CBLT/CBDT, OT-SVG color formats, but not COLR/CPAL (unless we can trace them but that's non trivial). The (vector) SVG sources can be used for generating all four color formats (for sbix and CBLT/CBDT we would use skia or cairo to rasterize). SVG with mixed vector/bitmap graphics are tricky, and I'll ignore them for now.

The primary source format (UFO) needs to be extended to support storing references to SVG files, which may contain vector paths (either filled or stroked) and the respective transforms, colors, gradients, or even embedded bitmap images. Currently the UFO GLIF spec only allows PNG as images. These are traditionally understood as background images to be used while designing, rather than for exporting color or icon fonts.
Ideally I'd like to have first-class support in UFO for color fonts, but I could live with using the data subfolder plus some glif lib keys pointing to svg files until the workflow stabilises and consensus can be reached.

Then we need a way parse SVGs into something that fontmake (or rather ufo2ft) can consume from python. FontTools has an svgLib that can parse paths' d strings, as well as some primitive geometric shapes. However for better SVG support, I am thinking of using Adobe's https://github.com/adobe/svg-native-viewer (a c++ lib) to extract the SVG drawing commands by writing a custom SVGRenderer that serializes them as json (or something we can easily deserialize from python). There's already a StringSVGRenderer that dumps them as text for testing/debugging. I could write a small C++ lib that dumps svg-native to json and call it from python (via ctypes, or running executable as subprocess). Or I could write a cython extension module that implements a custom SVGRenderer class that directly call backs into python code, thus skipping the json part altogether (depends on how involved this turns out to be).

SVG-native is of course only a subset of SVG. Ideally we will have some method for converting from SVG to SVG-native (e.g. linebender/resvg#135).

I plan to use noto-emoji as a test font to experiment with this build workflow, since it has both SVG and PNG sources.
Behdad suggested that I first attempt to compile a sbix version of Noto Emoji font, given that sbix is the simplest among the bitmap color formats, and then proceed from there to add support for the other formats.

Let me know if you have any comments or suggestion, thanks.

[davelab6]

https://github.com/djrrb/Bungee/tree/master/fonts/Bungee_Color_Fonts are available for testing

It was built with https://github.com/jenskutilek/RoboChrome which has its own demo fonts, https://github.com/jenskutilek/RoboChrome/tree/master/demo

[rsheeter]

https://github.com/twitter/twemoji is likely another good test set for svg.

[anthrotype]

Thanks for the links. I also started a shared doc here:
https://docs.google.com/document/d/1DlZwm18yZl5R7zpc-Fj9-CZglokB_RX_2kx0RvBKTus/edit?usp=sharing

[justvanrossum]

I commented this on the shared doc:

I am against using SVG as a source format within UFO as it's a completely parallel world that has very little in common with the rest of UFO, and requires completely different paradigms for editing.

Also: using UFO layers as color font sources has the huge advantage is that everything that works for regular outlines "just works" for color layer outlines. Not just manual editing, but also scripting functionality. It's all there.

[typesupply]

I agree very strongly with what @justvanrossum said. UFO layers were designed with color fonts as one of their primary use cases. If layers don't support something that is needed, address it from that angle rather than adding a new deeply complex outline type.

[behdad]

Given the attitude shown, I suggest those of us who actively work on extending OpenType fork UFO and be done with gatekeepers.

[LettError]

@behdad is that some sort of entitlement thing you picked up at Facebook?

[justvanrossum]

I don't understand.

1. UFO in no way prevents people from building an SVG-as-source workflow (lib + data folder to the rescue)
2. Allowing SVG in the image element would not make such a workflow inherently better
3. We haven't even said "no" to that proposal yet

Just because we don't immediately give in to your wishes you get to call us gatekeepers with an attitude? I think that is way out of line and abusive.

[behdad]

@behdad is that some sort of entitlement thing you picked up at Facebook?

You are right. I apologize. :)

I think changing UFO image element to allow other image types is a change that should be made without much resistance. What other tools (fontmake) does with that image or the layers, is outside the scope of UFO itself to specify.

If layers don't support something that is needed, address it from that angle rather than adding a new deeply complex outline type.

This doesn't make sense to me. Emoji are designed by graphics designers in graphic design tools. Are you saying we must force them to design emoji in font design tools only?

• Allowing SVG in the image element would not make such a workflow inherently better

I disagree.

[LettError]

UFO in no way prevents people from building an SVG-as-source workflow (lib + data folder to the rescue)

What is so wrong with this option that it requires a tool-breaking change to the spec?

[anthrotype]

No need to fork anything :)
When I suggested to use the GLIF image element to point to an SVG image, I was simply following what appears to me logical. Glyphs.app also uses the GSLayer's backgroundImage structure to point to the external image file, irrespective of the image format, so there's another precendence of reusing what was originally designed for background image for the purpose of producing color fonts. In glyphsLib we already convert to/from GSLayer.backgroundImage <=> GLIF.image (although ufoLib has a validator that will complain if the format is not PNG).
Anyway, I can work with data dir and glyph.lib for now.

[behdad]

UFO in no way prevents people from building an SVG-as-source workflow (lib + data folder to the rescue)

What is so wrong with this option that it requires a tool-breaking change to the spec?

1. I'm not /necessarily/ saying anything is wrong with that. My argument is that UFO /spec/ should /not/ specify what image formats are allowed. The same way that HTML doesn't specify what image formats are allowed in an img tag destination! It's not even like the format of the image file is specified in UFO!

To me, the spec should /not/ say anything other than maybe a note that PNG is the widely supported format. It's up to each implementation to decide what to implement.

2. Now to what /is/ wrong with that: Then the workflow in question will /forever/ become a custom fontmake thing. It means, font design tools (Glyphs, Robofont, ...) should opt into supporting fontmake UFO extension to allow color fonts build.

The alternative I prefer is, UFO spec is updated to /allow/ other image formats. fontmake consumes them, then we ask font editor developers to please support other image formats in their next versions. For the most part they don't even care. They are using system libraries to render the image anyway, and it probably transparently automatically already work for JPG and SVG anyway. In that scheme, there's no need for (all!) font editors to support any fontmake-specific extensions whatsoever.

That was the original design goal of fontmake from the beginning: to consume whatever sources people work with naturally. Using fontmake extensions makes fontmake broken for people who just want to edit things in an editor and call fontmake on the results.

Does that make some sense?

[rsheeter]

To provide context (not sure if this is common knowledge or not), at Google today (and I believe other places as well) designers often work in design tools that readily output SVG and never touch a font editor when building icon or emoji fonts. The ability to feed fontmake a pile of svgs plus some metadata and get out a functional color font, particularly if COLR gains gradient support, is thus very desirable.

[typesupply]

I'm not /necessarily/ saying anything is wrong with that. My argument is that UFO /spec/ should /not/ specify what image formats are allowed. The same way that HTML doesn't specify what image formats are allowed in an img tag destination! It's not even like the format of the image file is specified in UFO!
To me, the spec should /not/ say anything other than maybe a note that PNG is the widely supported format. It's up to each implementation to decide what to implement.

This is precisely what I was trying to prevent by restricting it to PNG. One of my initial drafts of UFO 3 said that anything was allowed. While I was developing the spec I was also building an implementation (ufoLib, defcon, defconAppKit) of it to check the feasibility of what I was specifying. I quickly fell down the rabbit hole of supporting every image format and decided to go the opposite direction and lock the format down very specifically. I didn't want to get into a situation where a user opens a font in one editor and doesn't see official data because the editor developer chose not to support something. (You know me. I'm always trying to keep things consistent for the user. :)

---

Backing up a little bit, I think I understand the problem that you are trying to address. Is this a good summary?

• The UFO layer model has consistent layers, layer order, colors, etc. across all glyphs.
• Emoji/icons have layers, layer order, colors, etc. that may or may not be unique to each glyph.

(If that's not accurate, please let me know.)

This was a significant design challenge in UFO 3. There were times when I had a model that would allow individual glyphs to have their own layer details rather than the layer details being consistent across the whole font. I also had a draft that specified fill color, stroke color, stroke width, stroke dash, everything for individual contours. Erik pointed out that I was reinventing the Illustrator file specification and that it was going to be extremely difficult for editors to support all of this. He was right, I went back to a more abstract layering system and figured that if we needed more complexity we'd address it when it came up. So, I guess this is the needed complexity coming up. :)

My concern about using the <image> element to store the SVG is that the element was designed for reference within the glyph, for example a sketch to trace over, not to be a storage place for actual content in the glyph. (I know, the spec isn't clear about this and it is a murky difference.) If we need a place to store image content, we should make something new rather than repurposing <image>.

I very much like the idea of keeping the SVG in an external file and making a reference to the file rather than putting the SVG's XML inside of GLIF. (Putting SVG inside of GLIF was something else I explored in UFO 3. It made parsing very difficult. I shudder at the thought of what it would have meant for validating and normalizing.) We could do this with these changes:

1. In the GLIF lib, establish a new public.svg key with the value being a file name.
2. In the data directory, establish a new public.svg sub-directory that contains the referenced svg files.

This could be implemented pretty easily and it wouldn't be a breaking change. This is the kind of use case that <lib> and the data directory were designed for. The rules that govern how they are handled would mean that existing tools wouldn't need to change to support this.

What do you think?

---

PS: Should this discussion move to the UFO Spec issue tracker since we're talking about a UFO change?

[twardoch]

Behdad is right to say that the HTML does no specify image formats. But UFO is not independent of OpenType — it heavily references OpenType. In a sense, UFO is a bit subordinate to OT. And OT does currently limit image formats a bit.

I also agree that SVG should not be treated the same way as bitmap images. I can see how one structure could be expressed generic "image", and not necessarily dictate whether the image should be JPG, PNG, WebP or HEIC.

But SVG is very different. For starters, it’s XML. SVG that is used in fonts actually contains data that is font-specific.

Let’s also remember that SVG in OpenType can contain a number of SVG documents which may be used by glyphs, but this is an n:m relationship.

It’s extremely limiting to assign some SVG document to just one glyph. If you want to use SVG “components” (the g element i.e. a symbol), you may want to put both the component sources and the composite glyphs into one SVG document. Which is very advisable, otherwise the font becomes huge. (The element references mechanism in FontLab is modeled similarly to SVG g symbols).

Let’s also not think that SVG in fonts is somehow limited to emoji. Just saying :)

[twardoch]

How would the UFO select the right data within one SVG document that represents a glyph? In OT, there is a mechanism for that.

[typesupply]

Let’s also not think that SVG in fonts is somehow limited to emoji. Just saying :)

+1 :)

It’s extremely limiting to assign some SVG document to just one glyph. If you want to use SVG “components” (the g element i.e. a symbol), you may want to put both the component sources and the composite glyphs into one SVG document. Which is very advisable, otherwise the font becomes huge. (The element references mechanism in FontLab is modeled similarly to SVG g symbols).

Good point. Modeling the structure GLIF lib's public.svg value on the SVG table would be a good place to start.

[justvanrossum]

In the meantime, here is something that works: googlefonts/ufo2ft#359

[behdad]

I feel like there's a lot of miscommunication going on. Let me explain what I suggest Cosimo do. These are my personal opinions, and I'm not a maintainer or developer of either fontmake or ufo2ft.

What is so wrong with this option that it requires a tool-breaking change to the spec?

I'm confused as to how the spec allowing more image types is deemed as "tool-breaking change", whereas adding a new public.svg key is not.

Anyway. Here is my plan; I hope each step is self-motivating, and the full picture would justify the design. Before that, I like to inform you all of two ongoing developments:

• There is work on specing a very small subset of SVG, called SVG Native, with the plan to then restrict OT-SVG to just SVG Native. Currently there exist only one implementation, svg-native-renderer, developed by Adobe. To my knowledge there exist no tools that output SVG Native.

• There is work that I have been slowly pushing, to add linear and radial color gradients to the Microsoft COLR/CPAL format. Proposal.

Plan

sbix

Add an option to fontmake, such that when something like --color-glyphs-source=image is provided, background images are packed into an sbix table by ufo2ft. Suggesting sbix because PNG and simplest.

CBLC/CBDT

Import code from noto-emoji / color-emoji repos to build CBLC/CBDT fonts in the same way. Add --color-font-format=cbdt/sbix (possibly with google/apple aliases). If both are provided, produce both if possible. At least one must be provided if --color-glyphs-source=image is provided.

Producing both might not be possible since sbix requires glyf table to be present whereas CBDT/CBLC requires that it not be. The latter should be fixed in FreeType implementation and relaxed in spec.

PNG Optimizations

Import the PNG optimizations from noto-emoji repo and possibly add as ufo2ft filters. Pick sane defaults for all tools, but feel free to connect up their knobs to the command line. Follow the proposed fontmake's -O optimization level to make sensible decisions as to what filters to activate and configure.

fontTools.colorLib.builder

Move the sbix- and CBDT/CBLC-building code from ufo2ft into a new fontTools.colorLib.builder module. Model after fontTools.[varLib/otlLib/feaLib].builder, with functions taking data in Pythonic structures and returning fontTools table objects.

fontTools.colorLib.convert

While at that, add fontTools.colorLib.convert runnable module to convert between various color font formats. Initially just implement sbix <=> CBDT/CBLC conversion.

Color Layers

Add --color-glyphs-source=layers to fontmake to use layers and their colors.

Add colr (and possibly microsoft) to --color-font-format values. If layers are provided and colr format is requested, build COLR/CPAL tables by adding them to fontTools.colorLib.builder and invoking from ufo2ft.

If layers are provided and PNG color output (sbix/cbdt) are requested, rasterize the color glyph at a preset (128?) size. Possibly do this only if an additional option is provided. While implementing this, add COLR support to fontTools.colorLib.convert.

If only background-images are provided and colr output requested, err.

It's possible to provide both of images and layers, and possible to request colr as well as sbix/cbdt. In that case, I think we should encode the images in PNG tables and the layers in colr only. I'm not sure. Should test Apple/Microsoft/FreeType to see how they support a font that has both COLR/CPAL and sbix tables and different glyphs are present in one or the other or both.

If any of the layers uses foreground color (check that UFO allows this), conversion to PNG would be problematic as can only be done by fixing foreground color to either black or white, depending on default CPAL palette properties. With sbix might be possible to encode the foreground part of the image in the glyf table. skiaPathOps can be used to clip the foreground colors to color layers on top. This assumes that glyf shapes are rendered behind the sbix image. Check the three implementations for this (I know FreeType ignores the glyf entry; fix?) Suggest OpenType be changed to require this, and require same for CBDT/CBLC.

In comes OT-SVG

Add --color-font-format=svg output format. Generate SVG from provided PNG or color layers. If both values are provided to --color-font-format, prefer the one that is specified first.

And UFO-SVG

Accept SVG (and possibly SVG Native; should be treated same or differently?) in the background image (the contentious proposal).

If PNG output formats (sbix/cbdt) are necessary invoke updated fontTools.colorLib.convert to rasterize SVG (using librsvg from Python render to cairo surface.) or SVG Native (using svg-native-renderer to render to cairo), then proceed with optimizing PNG`.

If OT-SVG output format is requested, use resvg's proposed functionality to convert SVG input to SVG Native document.

Add filters and sane defaults to optimize the SVG Native. Use svgo for optimization. Add filter to svgo to simplify path details to within .5, 1, or a few font units. This is particularly necessary for noto-emoji's country flags, as the flags are sourced from Wikimedia Commons, and the ones that have map of region on the flag can cost up to 300kb.

Possibly try extracting common elements from the SVG from various glyphs and share them by encoding them together in one SVG Document. Possibly proves not worth the effort. Add API and invocation for it to facilitate experimentation, possibly by connecting to external tools if exist.

Add option for svgz output. That has been supported in Firefox for 3 months now.

Organize utility functionality nicely in fontTools.svgLib and new fontTools.pngLib.

SVG => COLR/CPAL

If COLR/CPAL output is requested, use to-be-developed [port](https://github.com/adobe/svg-native-viewer/tree/master/svgnative/port] to svg-native-viewer to draw the SVG Native into a series of shape-paint commands that are wired back (possibly via JSON) into Pythonic structures.

If no color gradients are used, encode a COLRv0 table.

If color gradients are used and a COLRv0 output is requested, warn with names of glyphs using gradients, and flatten each gradient to the single color deduced by the weighted average of the gradient's color-stops.

If the proposed COLRv1 output is requested, then encode any glyphs using gradients (and only those) in the COLRv1 portion of the table, while encoding glyphs with only solid colors in the COLRv0 portion. This saves a few bytes.

If both COLRv0 and COLRv1 are requested, for glyphs with gradients also include the flattened-to-average solid-color version for the COLRv0 portion of the table. No warning necessary in this case.

Closing

My aim is to make building color fonts easy and accessible to most designers.

To that end, I deem necessary that our formats and tools allow for a wide variety of requested input schemes (PNG, SVG, layers) which each lend best to certain types of workflows and designs. There is no right solution.

I also deem it necessary that we be able to generate output in a wide variety of formats suitable for different environments, to enable wide deployment.

This is a lot of work, but I hope I have shown a roadmap that is coherent, attainable, simple to use, and clean in design. Google Fonts / Cosimo has kindly volunteered to build all the tools. :D The rest of us can help by taking care of OT / UFO / Freetype / Apple / Microsoft parts of the work.

Thanks :)

[justvanrossum]

I'm confused as to how the spec allowing more image types is deemed as "tool-breaking change", whereas adding a new public.svg key is not.

Because tools need to be updated if they don't want to crash on image formats that they previously didn't expect, whereas a lib key is a new addition, that tools can opt-in to implement at their leisure. I think that's a huge difference. The specified lib and data folder behavior ensures that tools that do not know about specific keys or data items will not corrupt the "unknown" data, even when performing "save as".

The rest of your proposal sounds great.

[behdad]

I'm confused as to how the spec allowing more image types is deemed as "tool-breaking change", whereas adding a new public.svg key is not.

Because tools need to be updated if they don't want to crash on image formats that they previously didn't expect,

Thanks. I understand your point of view. But let's be realistic: most tools don't open the image. Those will keep working. Font editors render the image. If they crash on a bad image file, that's really a bug in the editor that needs to be fixed. I highly doubt they crash.

If someone has scripts or plugings, etc that open the image and only work if it's PNG, then those tools need to be updated before they can consume UFO's using the proposed features. But that's life with all standards. Data using new spec features needs tools to be updated to fully understand it.

The rest of your proposal sounds great.

Thanks.

[typesupply]

@behdad I'm very confused by your resistance to the lib/data proposal. Repurposing image is going to cause backwards compatibility problems, has the strong potential for data loss, doesn't allow room to address the issues @twardoch raised, forces large amounts of work on volunteers, will compel users to upgrade parts of their toolchain before they are ready to do so and more. The lib/data proposal has none of those problems. Is there some reason that image must be used?

[behdad]

@behdad I'm very confused by your resistance to the lib/data proposal.

See #30 (comment)

Repurposing image is going to cause backwards compatibility problems,

See my previous reply: #30 (comment)

has the strong potential for data loss,

Hyperbole.

doesn't allow room to address the issues @twardoch raised,

Which issues particularly? Let's talk about actual issues one by one.

forces large amounts of work on volunteers,

Please explain. I have no clue whatsoever what you are talking about.

will compel users to upgrade parts of their toolchain before they are ready to do so and more.

Again, no idea what you are talking about.

The lib/data proposal has none of those problems. Is there some reason that image must be used?

I don't care what approach is used. What I care about is to make fontmake make color fonts from sources that can be designed / manipulated easily, mostly using existing font editors. Any lib/data addition would require font editors to be updated. making Glyphs or Robofont render SVG images on the other hand is a trivial change.

I'm going to stop replying to unsubstantiated comments from now on. I'm interested in designing and building things.

[typesupply]

I'm going to stop replying to unsubstantiated comments from now on.

I can and have substantiated all of this (and more) for you over many years. You continue to dismiss anything I say that doesn't match your immediate desires.

I'm interested in designing and building things.

Likewise. I'm done with trying to reason with bullies.

[behdad]

I'm going to stop replying to unsubstantiated comments from now on.

I can and have substantiated all of this (and more) for you over many years.

Really? You and I have not communicated much. Definitely not about color fonts.

You continue to dismiss anything I say that doesn't match your immediate desires.

I'm interested in designing and building things.

Likewise. I'm done with trying to reason with bullies.

Sure. Become one.

[LettError]

@behdad you’re ignoring a proposal that solves your immediate needs.

[behdad]

@behdad you’re ignoring a proposal that solves your immediate needs.

I have no immediate need or any stakes on this whatsoever. I'm providing what I think is a good design. Who does what with it is separate.

[twardoch]

I’m siding with @typesupply on this. @behdad — unfortunately (or not) SVG objects are not images, certainly not the way they've been implemented in OT+SVG. The relationship between font glyphs and SVG documents is an n:m one, and this actually is great, because it allows the re-use of SVG g symbols in different glyphs in a flexible way. This stuff is much more like CFF subroutines or FontLab’s elements, and is a legitimate mechanism for component-like structures.

I feel that treating SVG like "scalable PNGs" is way too limiting, and is not necessary. This might work for emojis, but even there you have a lot of repetitive shapes. Running svgo only solves a part — but SVGs can be really smart sources, and if used smartly, they can reduce the size a lot. But not with the "like PNG" approach.

I think a dedicated data structure is better, one that allows the n:m mapping that is paramount to the efficiency of SVG-based OT fonts.

[rsheeter]

Fwiw for emoji we expect to make the compiler identify reusable elements for both svg and colr.

[behdad]

@twardoch I think you are conflating separate things.

SVG as image input should be supported. That's independent of OT+SVG or any other output technology. By suggesting that UFO needs to add new syntax for SVG.. that's just bad design. Imagine if imaging libraries made you call different API names to open different types of images. To a designer / user an image is an image. JPEG and PNG are extremely different internally and in what each is good for. Would you argue that they would need to be addressed differently in HTML, other places?

OT+SVG is not SVG. Get over it. Now, the compiler should convert SVGs into OT+SVG table if asked to. The compiler should also optimize, while possibly giving lowlevel control if desired. But you can't just drop any SVG in OT+SVG. So there's gonna be need for a compiler.

And guess what, is trivial to see how UFO should support manual SVG element sharing. Make the UFO glyphs refer to eg. "emoticons.svg#smiling-face". What's problem with that? Also, compiler needs to rewrite the element names to reflect glyph numbers anyway. Compiler can also optimize and remove unused elements.

Imagine every time Intel released CPUs with new features we ran and changed our programming languages to add those features. We don't. We extend the programming language in generic extensible ways, and we make compilers generate faster better code given the same input.

[behdad]

...Same way that we don't require designers design with quadratic curve if they intend to generate TrueType. The compiler takes care of it.

If certain designers find designing using quadratics better for certain usecases, that's says nothing about TrueType outlines being better than CFF. That just says there are usecases that it makes sense for the design tool to let designer use quadratic curves. Compilers know how to convert quadratic<->cubic so the output is completely irrelevant.

[behdad]

There are emoji fonts that start with vector assets. And there are emoji fonts that start with bitmap assets. And in both cases, it's desired to generate emoji fonts that work on a wide variety of platforms. Decoupling input and output is just good software design / architecture.

[schriftgestalt]

SVG can do all kind of crazy/cool stuff: scale, move, reference other pieces. But how to make a svg that really uses those things? Svgs for color fonts are 100% made by designers in design tools and everyone treats them as an image format. So building a spec around a theoretical use case and making it more complicated for everyone? So I’m with @behdad on this.

[yarmola]

Just to add some info about what "tools" do: In FontLab we do both: we have internal structures which mimic simplified SVG (and which are fully editable with the current exception of gradients) + we have SVG-as-image that is "just rendered".

On the other hand our PhotoFont color font format supports reference to the image as rectangle inside the bigger image, which is somewhat similar to what OT-SVG can do.

[davelab6]

What is the current state of building color fonts with fontmake today?

[justvanrossum]

COLR/CPAL can be built from layered UFOs, given the right lib keys. Some details are here: googlefonts/ufo2ft#359, but more documentation would be better.

[davelab6]

So, not possible to build SVG-in-OT fonts with fontmake?

[anthrotype]

no, not at the moment. You can try use nanoemoji.