Ceci est une ancienne révision du document !
This month, we’ll conclude our dive into the new text features in Inkscape version 1.0 by looking at a pair of new font formats that are now supported (and one that possibly isn’t). Although I’ve used the term “font formats”, you won’t find any new file extensions in use. These formats are implemented inside the standard OpenType Font (*.otf) files that are commonly used on modern computer systems. As such, you can’t immediately tell if a font supports these new features from the file extension alone, but we’ll look at a solution to that problem later.
Colored Fonts
The first font variation to discuss is termed “SVG in OpenType”, and it’s pretty much what it sounds like. With these fonts, the shapes of the glyphs are defined using the SVG format, and then bundled into the OTF wrapper in order to benefit from many of the typographical capabilities that come with it.
Basic OTF fonts just define shapes for each glyph, with no concept of color. The program that renders the fonts is responsible for filling or outlining the shapes to make them visible, often with a solid tone, but it could equally be with a gradient or pattern. The key point is that the font provides the path outlines, and the program draws those outlines as coloured objects. With an SVG in OpenType font, this choice is usually taken out of the application’s control, with colors defined solely by the font itself. Let’s look at an example.
You’re probably familiar with the Rainbow Flag, used as an emblem of gay, lesbian and related communities. The man who originally designed it, Gilbert Baker, passed away in 2017. In his memory, a free color font was created which was inspired by the Rainbow Flag, and named Gilbert. Due in part to the fact that there are currently very few color fonts in existence, and that even fewer are free of charge, this one is commonly used in articles about color font support in various browsers and other applications. This piece is no different, so here’s a screenshot of Gilbert Color in action within Inkscape version 1.0:
The first thing to note is that it doesn’t appear in color within the font selection drop-down, nor in the list in the Text and Font dialog. Neither is there any marker or indication that this is a color font, other than its name. It appears amongst all the other fonts in alphabetical order, rather than being separately grouped. This means that you’ll need to keep track of the names of any color fonts you add to your system, as they won’t always stand out obviously for selection in the UI.
The second thing to note is that it is, indeed, colorful. As is the case with many color fonts currently, the use of color is brash and obvious, rather than being used for subtle shadows or ornaments. But what happens if the colors used in the font aren’t quite what you want to fit in with your own design project? Unfortunately the answer appears to be “tough luck”.
In the previous image I have made four copies of the text, as follows: • With a black fill and no stroke • With no fill and no stroke • With a red fill and thick blue stroke • With no fill and a thick blue stroke
As you can see, removing both the fill and stroke causes the text to be transparent, but if any fill or stroke color is applied, then you get the colored font in exactly the colors that the designer intended, regardless of the color you apply.
If we can’t change the colors in the font using the normal fill and stroke, perhaps we could convert to paths and change the individual parts of each letter that way, right? Wrong.
In the image below, I’ve converted the top text – with a translucent red fill and blue stroke – to paths, using Path > Object to Path. As you can see, the result is what you would expect from a “normal” non-color font. I specifically used a translucent fill to show that the appearance of overlapping shapes in the original font does not result in overlapping sub-paths after the conversion.
The bottom example has a red stroke set, but no fill, as can be seen at the left-hand side of the status bar. I’ve used Path > Stroke to Path on this version, but Inkscape has left it untouched, claiming in the status bar message that there are “No stroked paths in the selection”.
This inability to preserve the colors – when performing an Object to Path conversion – does somewhat limit the usefulness of colored fonts. Using Object to Path is a common operation to “fix” the style of your text when you can’t be sure that the recipient has the font in question – such as when creating an SVG file for use online, or exporting to a PDF. Obviously a solid-fill conversion of the font will not produce the same results at all in these situations.
Instead of performing a conversion, it is possible to load an SVG file containing colored fonts directly into a web browser, either as a local file or by serving it online. However, even if the end user has the font installed on their machine, their experience will vary significantly depending on the browser they use. While Firefox displays Gilbert Color in all its prideful hues, the latest release of Chrome (89 at the time of writing), will show just a solid-filled version.
Similarly, when exporting a PDF from Inkscape, you might be tempted to use the option for embedding the font. My non-exhaustive test of PDF viewers suggests that this may result in a file that can’t be opened at all by some applications. Selecting the “Convert text to paths” option in the Save As… dialog results in a readable file, but only because the text is, once again, flat-filled with a single color.
Exporting to a PNG does work correctly. If you wish to create an SVG file for use online, however, the best option may be to use Edit > Make a Bitmap Copy in order to embed a bitmap version of your text into the SVG content, should you wish to ensure its colorful appearance across different browsers.
One final tip: if you do want to use different colors to those encoded in the file, you may be able to achieve the result you’re looking for by applying a filter. Be aware that this approach gives you only limited control over the choice of colors – unless you’re a filter expert who is prepared to spend a long time crafting a complex filter chain. In this final example, the top image is the original text in its natural colors, whereas the other three were the result of randomly using some of the filters from the Filters > Color submenu.
Bitmap Fonts
There’s an interesting side-effect of allowing SVG content in OpenType files. Due to the fact that SVG content can include embedded bitmap graphics, this format offers a backdoor through which bitmap fonts can be created. Of course, these are not the bitmap fonts that were prevalent in the 1980s – the OpenType wrapper imbues them with many modern font capabilities, if properly constructed. And unlike the pure bitmaps of the past, these modern files can seamlessly combine vector and bitmap content as required.
Bitmap fonts tend to result in larger files than their purely vector counterparts. For retro-styled fonts that hark back to video game text from decades ago, the size may still be modest. But many bitmap fonts are created to simulate brush strokes, spray paint or photographs of physical objects, at a high resolution, which results in very large file sizes.
If SVGs in OpenType fonts are relatively rare, the bitmap-based subset is rarer still. Finding free fonts that fit this definition is even more of a challenge. So take my Inkscape findings with a pinch of salt, as they’re based on a single sample of just one font.
I installed a brush-stroke font called Macbeth on my system, and tried using it in Inkscape 1.0 (and also the recently released 1.1 beta). In the font drop-down, and in the Text and Font dialog, the previews showed exactly what I had hoped for: translucent brush strokes in a dynamic, script style font.
On the canvas, however, it is a completely different matter, as shown in the image below. Either there’s a problem with the font, or an issue with Inkscape’s ability to deal with bitmap-in-SVG-in-OpenType files. I suspect the latter, but the fact that the previews work gives me hope that this is a temporary issue that will be fixed in a future update.
Despite Inkscape’s refusal to render the font correctly, Firefox does display the font as intended within an SVG file. Oddly, despite not supporting color fonts, Chrome does also display the Macbeth font correctly when included in an SVG file, sending somewhat mixed messages about its support for SVG in OpenType.
Variable Fonts
Typefaces typically live in “families”, consisting of related fonts that vary in weight or style. A single typeface may consist of a large number of separate *.otf or *.ttf files, each holding a separate variation, such as light, bold, black, condensed, expanded, italic or some combination of these. But as non-bitmap fonts are usually made up of the same basic paths which are tweaked for each variant, wouldn’t it make more sense to have just a single font file, and expose different parameters for controlling the path shapes? That is the premise behind “variable fonts”.
A variable font file – once again in a *.otf wrapper – is typically larger in size than an individual font, but considerably smaller than an entire family. It exposes a number of parameters, which are referred to as “axes” and which can potentially control any aspect of the font’s design. The original designer chooses which parameters to expose, with each axis being assigned a cryptic four-character name. Those names are also mapped to more human-readable versions within the font file, but we’ll come back to that shortly.
As well as the individual axes, the designer can also define “named instances''. These are specific collections of axis values that are given a name. For example, the designer might include a “Weight” axis that runs from 0 to 1000, but define some named instances for “Light” (300), “Regular” (500), “Bold” (700), and Black (“1000”). If the font also had a “Slant” axis, then the named instances might also include options such as “Bold Italic” and “Light Oblique”. Think of named instances as being a shortcut to a pre-defined set of parameters, so you don’t have to tweak them all yourself.
In keeping with the tradition forged at the start of this article, I’m going to use the same example font as every other article to demonstrate the use of variable fonts. Decovar is free of charge, and offers a wide selection of axes which can result in combinations of glyph shapes ranging from the conventional through to the bizarre. Here are a few examples rendered in Inkscape and, remember, these are all created from a single font file.
Within Inkscape, the axes are adjusted within the Text and Font dialog. You can see them displayed as a series of sliders just above the font preview in this screenshot. Note that there’s a scrollbar on the right to access more sliders: Decovar exposes 15 different axes in total!
Unfortunately, Inkscape has a few problems in both the design and the implementation of this feature. First is that the sliders are labelled with the four-letter internal names of the axes, rather than the human-readable names that the font supplies. The second is that the named instances aren’t exposed in this dialog, so you have no choice but to set the sliders yourself rather than using the designer’s preferred presets.
The biggest issue, however, is that the area that holds the sliders is allowed to grow and shrink according to the available space, but the lower limit is too small. If your font size is large, and your dialog height is small, the sliders can easily collapse down until only one is visible, making it extremely difficult to work with them. My advice is to keep the font size set at a small to moderate value, and the dialog as tall as you can, while you adjust the various axes. Once you’re happy with the parameters you can then increase the font size again, should you need to.
Unlike color fonts, variable fonts do appear to be converted correctly when using Path > Object to Path. Conversely, although variable fonts have broad support across current browsers, SVG files created using Inkscape don’t display correctly, falling back to the basic font as though all axes are set to zero. Clearly there’s a mismatch between the CSS that Inkscape is creating, and what is expected by browsers. Further investigation is required on this front but, for now, if you wish to use variable fonts in your SVG files you should probably convert them to paths before deploying the files online.
Font Information
Although Inkscape doesn’t tell you the human-readable names of the axes, doesn’t expose the named instances, and doesn’t indicate which fonts contain SVG content, there’s a way to explore the information encoded in your fonts which can help to overcome some of these shortcomings.
The bizarrely named “wakamai fondue” website is an invaluable tool. Just drag-and-drop a *.otf or *.ttf file onto the page, and a host of details about the font are extracted from the file. The processing all happens locally, without the font itself being uploaded to their server, so there are no licensing issues to worry about.
Where it’s particularly useful is with a variable font. Here’s a section of the output for Decovar:
Here you can experiment with the various axes (complete with human-readable names), or select from the “Instances” popup. When you’re happy with the combination you’ve found, you can then laboriously apply each slider’s value to its equivalent in Inkscape, based on its four-letter name.
This tool offers a whole lot more information as well, and is a great way to check out the hidden capabilities of your fonts. In fact, through using the beta of the next version of the tool I was even able to discover that Gilbert Color actually offers five different variations on its color scheme, via the OpenType “alternatives” feature. Until Inkscape offers a way to access them, however, I guess we’ll have to stick to tricks with filters.
Links
Gilbert Color: https://www.typewithpride.com/ Macbeth: https://www.dafontfree.co/macbeth-opentype-svg-script-brush-font/ Decovar: https://github.com/TypeNetwork/Decovar/ Wakamai Fondue: https://wakamaifondue.com/