svg fonts

Jeff Peters

Could someone enlighten me about svg fonts please.
How much support do they have – is it the future?
And Is it possible to have each glyph as a high res image?
Thanks!

Thomas Phinney

Which kind of SVG fonts do you mean? (Although the answer to the second question is “yes” either way.)

I think OpenType-SVG is well on its way to becoming most common format for color fonts (and perhaps also for bitmap fonts). It is already the best supported of the formats. More people are making fonts in this format than the others. And there are technical reasons behind this, both in terms of ease of supporting the format and the flexibility/power of the format. It's not perfect, but it is pretty good and it is winning the color-font-format wars.

The older SVG font format I think will continue to exist in pockets, but won’t be any more widely used than it is today (which is to say: not very).

Although OpenType-SVG has a few restrictions on what you can do in the SVG portion, it is more than flexible enough for font purposes. It can handle bitmaps/pixels or vectors, and complex effects with either.

So, yes you can have a high-res pixel-based image for each glyph. Or a vector drawing (including color, gradients, transparency, etc.) that can be scaled to any size at all.

Andriy Dykun

Inside this technology there can be two types of images, raster and vector. Raster allows you to achieve photo-realism and special effects. The vector is known to be better at scaling.

Jeff Peters

Thanks, sounds interesting. The downside to raster image glyphs being the scalability of course – even if each glyph is 1200 ppi you can't scale it up much. And it seems things can get quite slow, too.

Jeff Peters

And yes Thomas, I was talking about OpenType-SVG – I didn't know of anything else.

ivan louette

Wich kind of curves are used in OpenType SVG ? CFF ot TTF ?

Thomas Phinney

Jeff Peters said:

Thanks, sounds interesting. The downside to raster image glyphs being the scalability of course – even if each glyph is 1200 ppi you can't scale it up much. And it seems things can get quite slow, too.

The font itself does not have pixels per inch on the design side, just pixels. The output pixel density is dependent on how the font is scaled at display time.

But if you mean glyphs that are 1200 pixels, yes, I expect that performance with such a font might be very bad—dependent also on the number of glyphs involved, the device doing the display, etc. etc. Such a font might best be used sparingly indeed.

If we are talking about drop caps where you might normally only use one on a page, of course that might be no problem in the main use case.... Except when somebody tries to display a substantial sample of the font, which happens pretty often! At least WYSIWYG font menus tend to use caching, but, well, general “ouch.”

ivan louette said:

Which kind of curves are used in OpenType SVG ? CFF or TTF ?

OpenType SVG supports most of SVG 1.1 (with a few specific exceptions). This support includes cubic Bezier curves (like CFF), quadratic Bezier curves (like TTF), and also elliptical arcs.

Note that while the math describing the curves is the same as that in CFF or TTF, there are major differences in implementation. OpenType SVG fonts do not support any kind of hinting code, so their on-screen rendering may be worse than, or at least differ, from that of fonts.

ivan louette

@Thomas Phinney Thanks a lot for your precisions.

Thomas Phinney

Oops, I missed a word. My last sentence should have read “their on-screen rendering may be worse than, or at least differ from, that of ‘normal’ OTF/TTF fonts.”

Henning von Vogelsang

SVG as a technology has ties to HTML 5 Canvas and modern CSS. It is often used as a foundation to animate things in applications such as Tumult Hype, because SVG itself can be made part of the web application’s code. Therefore I think SVG fonts could provide an easier, more accessible bridge for those developers utilizing SVG in their HTML 5 and CSS development. Imagine animated logos using an SVG font instead of outlined shapes directly.

All of this is just my speculation based on the little I know about these subjects.

seb.friedrich

Heyho Jeff Peters, you actually triggered me to finally contribute my first post instead of just reading the forum. I try to keep it as short as possible.

SVG fonts vs Opentype-SVG:
SVG in the still current version 1.1 allows to embed fonts to be used in text elements. From that it’s possible to also hold only a selection of symbols in an SVG file that has no visible output on its own, but could be used as kind of a webfont file. Here is a code sample. There are drawbacks with font features actually supported. These fonts render the worst while consuming the most space and support was dropped in major browsers already quite some time ago. Following that, the W3C in it’s current draft for SVG version 2.0 dropped the SVG font feature entirely, as there are just better alternatives. Opposite to that, Opentype-SVG is holding entire SVG graphics as glyph definition within a font.

Opentype color fonts:
There are 4 different standards that made it into the Opentype 1.8 spec, to my opinion it feels like a political decision - with the major goal of having at least something colorful available on each platform. Apple got his sbix, Microsoft CPAL/COLR, Adobe (supported by Mozilla) added the SVG type, Google wanted to have CBDT/CBLC inside. While Apple’s and Google’s approach use rasterized images, it’s quite obvious, that this is not going to survive for long. Even with CJK fonts there is one long term trend torwards vectorization, so it will be for color fonts as well. The race is going to happen between CPAL/COLR and SVG.

Support for web fonts:
You can say that CPAL/COLR is already good supported in Firefox, Chrome and Edge, so major browser engines are covered. SVG support is deviating, while Firefox most probably does best. Here is a nice little testing site pixelambacht.nl/chromacheck/

The same guy who made this test website, held this talk that basically gives a nice overview on the variants, their technical possibilities and to my opinion quite important for the website use case - the bandwidth cost! He shows a real font test case to compare sizes, see 28:16 in the video.

Personal opinion:

I don’t understand why Mozilla voted for the SVG approach and believe that Microsoft figured out the smartest solution. Here is why:

• COLR degrades gracefully to monochrome as color is added as additional information.
• COLR reuses the well tested and supported vector outlining algortihms, implementation cost (for the rasterization/shaping engines) is the lowest what ensures a high and quick adoption also beyond the web.
• COLR produces the smallest font file sizes.
• Through the CPAL mechanism, color management can happen outside of the font rendering through the application environment, as it just defines color indices, that could be remapped and managed externally. The font doesn’t need to define CMYK, sRGB, Adobe-RGB etc. to comply to various applications.
• COLR gives the best preconditions to even plot outlines with adhesive foil or any other form of physical cutting (even how to layer the colors is defined), the SVG spec for Opentype is too fuzzy here.
• COLR allows for hinting, that is still relevant as high-dpi screens are not going to reach quickly all these embedded (touch) screens, ranging from ATM machines to low power IoT devices with very little low res auxiliary screens.
• SVG with its conceptional bindings to CSS, SMIL and Javascript is far more than needed if just multiple colors and maybe some alpha transparency were the initial demand.
• SVG opens the door for a hole new set of security implications, as it is technically complex, allows links and scripts.
• SVG has a shifted orientation in it’s coordinate system, it doesn’t blend nicely with what is already there for traditional glyphs, alignment to baselines etc. can turn out to be a tricky thing to manage (gut feeling).
  

Finally the design(ers) perspective:
Fonts are mainly about symbols, highly reusable, a modular system to shape a text. This use case might expand from time to time, as Emoji did. Color and not just the letter form now optionally became part of the semantic nature of text symbols. I cannot see so far, why it needs the full SVG feature set to serve that purpose.

Thomas Phinney

Thanks, Seb! Lots of good thoughts.

I think SVG-OT’s capability to handle bitmaps as well as vectors, and to allow for gradients, are two significant strengths that are missing in COLR+CPAL. But I will grant you that COLR+CPAL has a number of strengths. My first thought was that SVG-OT would win in the long run, as one can also do bitmaps in that format, and everybody already has SVG rasterizers. But everybody already has TT rasterizers, as well.