path: root/doc/context/sources/general/manuals/evenmore/evenmore-fonts.tex

% language=us

\environment evenmore-style

\disabledirectives[fonts.svg.cached]

% \usemodule[scite]
% \usemodule[article-basic]
% \usemodule[abbreviations-logos]

\startcomponent evenmore-fonts

\startchapter[title=Modern Type 3 fonts]

Support for \TYPETHREE\ fonts has been on my agenda for a couple of years now.
Here I will take a look at them from the perspective of \LUAMETATEX. \footnote
{This chapter appeared in \TUGBOAT\ 40:3. Thanks to Karl Berry for corrections.}
The reason is that they might be useful for embedding (for instance) runtime
graphics (such as symbols) in an efficient way. In \TEX\ systems \TYPETHREE\
fonts are normally used for bitmap fonts, the \PK\ output that comes via
\METAFONT. Where for instance \TYPEONE\ fonts are defined using a set of font
specific rendering operators, a \TYPETHREE\ font can contain arbitrary code, in
\PDF\ files these are \PDF\ (graphic and text) operators.

A program like \LUATEX\ supports embedding of several font formats natively. A
quick summary of relevant formats is the following: \footnote {Technically one
can embed anything in the \PDF\ file.}

\startitemize[headintext][headstyle=bold]
\starthead {\TYPEONE:}
    these are outline fonts using \type {cff} descriptions, a compact format for
    storing outlines. Normally up to 256 characters are accessible but a font can
    have many more (as Latin Modern and \TEX\ Gyre demonstrate).
\stophead
\starthead {\OPENTYPE:}
    these also use the \type {cff} format. As with \TYPEONE\ the outlines are
    mostly cubic Bezier curves. Because there is no bounding box data stored in
    the format the engine has to pseudo|-|render the glyphs to get that
    information. When embedding a subset the backend code has to flatten the
    subroutine calls, which is another reason the \type {cff} blob has to be
    disassembled.
\stophead
\starthead {\TRUETYPE:}
    these use the \type {ttf} format which uses quadratic B|-|splines. The font
    can have a separate kerning table and stores information about the bounding
    box (which is then used by \TEX\ to get the right heights and depths of
    glyphs). Of course those details never make it into the \PDF\ file as such.
\stophead
\starthead {\TYPETHREE:}
    as mentioned this format is (traditionally) used to store bitmap fonts but as
    we will see it can do more. It is actually the easiest format to deal with.
\stophead
\stopitemize

In \LUATEX\ any font can be a \quotation {wide} font, therefore in \CONTEXT\ a
\TYPEONE\ font is not treated differently than an \OPENTYPE\ font. The \LUATEX\
backend can even disguise a \TYPEONE\ font as an \OPENTYPE\ font. In the end, as
not that much information ends up in the \PDF\ file, the differences are not that
large for the first three types. The content of a \TYPETHREE\ font is less
predictable but even then it can have for instance a \type {ToUnicode} vector so
it has no real disadvantages in, say, accessibility. In \CONTEXT\ \LMTX, which
uses \LUAMETATEX\ without any backend, all is dealt with in \LUA: loading,
tweaking, applying and embedding.

The difference between \OPENTYPE\ and \TRUETYPE\ is mostly in the kind of curves
and specific data tables. Both formats are nowadays covered by the \OPENTYPE\
specification. If you Google for the difference between these formats you can
easily end up with rather bad (or even nonsense) descriptions. The best
references are \typ {https://en.wikipedia.org/wiki/Bézier_curve} and the
ever|-|improving \typ {https://docs.microsoft.com/en-us/typography} website.

Support for so|-|called variable fonts is mostly demanding of the front|-|end
because in the backend it is just an instance of an \OPENTYPE\ or \TRUETYPE\ font
being embedded. In this case the instance is generated by the \CONTEXT\ font
machinery which interprets the \type {cff} and \type {ttf} binary formats in
doing~so. This feature is not widely used but has been present from the moment
these fonts showed up.

\TYPETHREE\ fonts don't have a particularly good reputation, which is mainly due
to the fact that viewers pay less attention in displaying them, at least that was
the case in the past. If they describe outlines, then all is okay, apart from the
fact that there is no anti|-|aliasing or hinting but on modern computers that is
hardly an issue. For bitmaps the quality depends on the resolution and
traditionally \TEX\ bitmap fonts are generated for a specific device, but if you
use a decent resolution (say 1200 dpi) then all should be okay. The main drawback
is that viewers will render such a font and cache the (then available) bitmap
which in some cases can have a speed penalty.

Using \TYPETHREE\ fonts in a \PDF\ backend is not something new. Already in the
\PDFTEX\ era we were playing with so|-|called \PDF\ glyph containers. In practice
that worked okay but not so much for \METAPOST\ output from \METAFONT\ fonts. As
a side note: it might actually work better now that in \METAFUN\ we have some
extensions for rendering the kind of paths used in fonts. But glyph containers
were dropped long ago already and \TYPETHREE\ was limited to traditional \TEX\
bitmap inclusion. However, in \LUAMETATEX\ it is easier to mess around with fonts
because we no longer need to worry about side effects of patching font related
inclusion (embedding) for other macro packages. All is now under \LUA\ control:
there is no backend included and therefore no awareness of something built|-|in
as \TYPETHREE.

So, as a prelude to the 2019 \CONTEXT\ meeting, I picked up this thread and
turned some earlier experiments into production code. Originally I meant to
provide support for \METAPOST\ graphics but that is still locked in experiments.
I do have an idea for its interface, now that we have more control over user
interfaces in \METAFUN.

In addition to \quote {just graphics} there is another candidate for \TYPETHREE\
fonts \emdash\ extensions to \OPENTYPE\ fonts:

\startitemize[packed,n]
\startitem Color fonts where stacked glyphs are used (a nice method). \stopitem
\startitem Fonts where \SVG\ images are used. \stopitem
\startitem Fonts that come with bitmap representations in \PNG\ format. \stopitem
\stopitemize

It will be no surprise that we're talking of emoji fonts here although the second
category is now also used for regular text fonts. When these fonts showed up
support for them was not that hard to implement and (as often) we could make
\TEX\ be among the first to support them in print (often such fonts are meant for
the web).

For category one, the stacked shapes, the approach was to define a virtual font
where glyphs are flushed while backtracking over the width in order to get the
overlay. Of course color directives have to be injected too. The whole lot is
wrapped in a container that tells a \PDF\ handler what character actually is
represented. Due to the way virtual fonts work, every reference to a character
results in the same sequence of glyph references, (negative) kern operations and
color directives plus the wrapper in the page stream. This is not really an issue
for emoji because these are seldom used and even then in small quantities. But it
can explode a \PDF\ page stream for a color text font. All happens at runtime and
because we use virtual fonts, the commands are assembled beforehand for each
glyph.

For the second category, \SVG\ images, we used a different approach. Each symbol
was converted to \PDF\ using Inkscape and cached for later use. Instead of
injecting a glyph reference, a reference to a so|-|called \type {XForm} is
injected, again with a wrapper to indicate what character we deal with. Here the
overhead is not that large but still present as we need the so|-|called \quote
{actual text} wrapper.

The third category is done in a similar way but this time we use GraphicsMagick
to convert the images beforehand. The drawbacks are the same.

In \CONTEXT\ \LMTX\ a different approach is followed. The \PDF\ stream that
stacks the glyphs of category one makes a perfect stream for a \TYPETHREE\
character. Apart from some juggling to relate a \TYPETHREE\ font to an \OPENTYPE\
font, the page stream just contains references to glyphs (with the proper related
\UNICODE\ slot). The overhead is minimal.

For the second category \CONTEXT\ \LMTX\ uses its built|-|in \SVG\ converter. The
\XML\ code of the shape is converted to (surprise): \METAPOST. We could go
directly to \PDF\ but the \METAPOST\ route is cheap and we can then get support
for color spaces, transformations, efficient paths and high quality all for free.
It also opens up the possibility for future manipulations. The \TYPETHREE\ font
eventually has a sequence of drawing operations, mixed with transformations and
color switches, but only once. Most of the embedded code is shared with the other
categories (a plug|-|in model is used).

The third category follows a similar route but this time we use the built|-|in
\PNG\ inclusion code. Just like the other categories, the page stream only
contains references to glyphs.

It was interesting to find that most of the time related to the inclusion went
into figuring out why viewers don't like these fonts. For instance, in Acrobat
there needs to be a glyph at index zero and all viewers seem to be able to handle
at most 255 additional characters in a font. But once that, and a few more
tricks, had become clear, it worked out quite well. It also helps to set the font
bounding box to all zero values so that no rendering optimizations kick in. Also,
some dimensions can are best used consistently. With \SVG\ there were some issues
with reference points and bounding boxes but these could be dealt with. A later
implementation followed a slightly different route anyway.

The implementation is reasonably efficient because most work is delayed till a
glyph (shape) is actually injected (and most shapes in these fonts aren't used at
all). The viewers that I have installed, Acrobat Reader, Acrobat X, and the
mupdf|-|based Sumatra\PDF\ viewer can all handle the current implementation.

An example of a category one font is \MICROSOFT's \type {seguiemj}. I have no
clue about the result in the future because some of these emoji fonts change
every now and then, depending also on social developments. This is a category one
font which not only has emoji symbols but also normal glyphs:

\startbuffer[1a]
\definefontfeature[colored][default][colr=yes]
\definefont[TestA][file:seguiemj.ttf*colored]
\definesymbol[bug1][\getglyphdirect{file:seguiemj.ttf*colored} {\char"1F41C}]
\definesymbol[bug2][\getglyphdirect{file:seguiemj.ttf*colored} {\char"1F41B}]
\stopbuffer

\typebuffer[1a][option=TEX] \getbuffer[1a]

The example below demonstrates this by showing the graphic glyph surrounded by
the \type {x} from the emoji font, and from a regular text font.

\startbuffer[1b]
{\TestA x\char"1F41C x\char"1F41B x}%
\quad
{x\symbol[bug1]x\symbol[bug2]x}%
\quad
{\showglyphs x\symbol[bug1]x\symbol[bug2]x}%
\stopbuffer

\typebuffer[1b][option=TEX]

\startlinecorrection
\scale[width=\textwidth]{\getbuffer[1b]}
\stoplinecorrection

In this mix we don't use a \TYPETHREE\ font for the characters that don't need
stacked (colorful) glyphs, which is more efficient. So the \type {x} characters
are references to a regular (embedded) \OPENTYPE\ font.

The next example comes from a manual and demonstrates that we can (still)
manipulate colors as we wish.

\startbuffer[1c]
\definecolor[emoji-red]   [r=.4]
\definecolor[emoji-blue]  [b=.4]
\definecolor[emoji-green] [g=.4]
\definecolor[emoji-yellow][r=.4,g=.5]
\definecolor[emoji-gray]  [s=1,t=.5,a=1]

\definefontcolorpalette
  [emoji-red]
  [emoji-red,emoji-gray]

\definefontcolorpalette
  [emoji-green]
  [emoji-green,emoji-gray]

\definefontcolorpalette
  [emoji-blue]
  [emoji-blue,emoji-gray]

\definefontcolorpalette
  [emoji-yellow]
  [emoji-yellow,emoji-gray]

\definefontfeature[seguiemj-r][default][ccmp=yes,dist=yes,colr=emoji-red]
\definefontfeature[seguiemj-g][default][ccmp=yes,dist=yes,colr=emoji-green]
\definefontfeature[seguiemj-b][default][ccmp=yes,dist=yes,colr=emoji-blue]
\definefontfeature[seguiemj-y][default][ccmp=yes,dist=yes,colr=emoji-yellow]

\definefont[MyColoredEmojiR][seguiemj*seguiemj-r]
\definefont[MyColoredEmojiG][seguiemj*seguiemj-g]
\definefont[MyColoredEmojiB][seguiemj*seguiemj-b]
\definefont[MyColoredEmojiY][seguiemj*seguiemj-y]
\stopbuffer

\typebuffer[1c][option=TEX] \getbuffer[1c]

\startbuffer[1d]
\MyColoredEmojiR\resolvedemoji{man}\resolvedemoji{woman}%
\MyColoredEmojiG\resolvedemoji{man}\resolvedemoji{woman}%
\MyColoredEmojiB\resolvedemoji{man}\resolvedemoji{woman}%
\MyColoredEmojiY\resolvedemoji{man}\resolvedemoji{woman}%
\stopbuffer

\startlinecorrection
    \scale[width=\textwidth]{\getbuffer[1d]}
\stoplinecorrection

Let's look in more detail at the woman emoji. On the left we see the default
colors, and on the right we see our own:

\definefontfeature[seguiemj][default][ccmp=yes,dist=yes,colr=yes]
\definefont[MyColoredEmojiD][seguiemj*seguiemj]

\startlinecorrection
\scale[height=2cm]
  {\MyColoredEmojiD\resolvedemoji{woman}%
   \MyColoredEmojiR\resolvedemoji{woman}}
\stoplinecorrection

The multi|-|color variant in \CONTEXT\ \MKIV\ ends up as follows in the page
stream:

\starttyping
/Span << /ActualText <feffD83DDC69> >> BDC
q
0.000 g
BT
/F8 11.955168 Tf
1 0 0 1 0 2.51596 Tm [<045B>]TJ
0.557 0.337 0.180 rg
1 0 0 1 0 2.51596 Tm [<045C>]TJ
1.000 0.784 0.239 rg
1 0 0 1 0 2.51596 Tm [<045D>]TJ
0.000 g
1 0 0 1 0 2.51596 Tm [<045E>]TJ
0.969 0.537 0.290 rg
1 0 0 1 0 2.51596 Tm [<045F>]TJ
0.941 0.227 0.090 rg
1 0 0 1 0 2.51596 Tm [<0460>]TJ
ET
Q
EMC
\stoptyping

and the reddish one becomes:

\starttyping[option=PDF]
/Span << /ActualText <feffD83DDC69> >> BDC
q
0.400 0 0 rg 0.400 0 0 RG
BT
/F8 11.955168 Tf
1 0 0 1 0 2.51596 Tm [<045B>]TJ
1 g 1 G /Tr1 gs
1 0 0 1 0 2.51596 Tm [<045C>1373<045D>1373<045E>1373<045F>1373<0460>]TJ
ET
Q
EMC
\stoptyping

Each time this shape is typeset these sequences are injected. In \CONTEXT\ \LMTX\
we get this in the page stream:

\starttyping[option=PDF]
BT
/F2 11.955168 Tf
1 0 0 1 0 2.515956 Tm [<C8>] TJ
ET
\stoptyping

This time the composed shape ends up in the \TYPETHREE\ character procedure. In
the colorful case (reformatted because it actually is a one|-|liner):

\starttyping[option=PDF]
2812 0 d0
0.000 g              BT /V8 1 Tf [<045B>] TJ ET
0.557 0.337 0.180 rg BT /V8 1 Tf [<045C>] TJ ET
1.000 0.784 0.239 rg BT /V8 1 Tf [<045D>] TJ ET
0.000 g              BT /V8 1 Tf [<045E>] TJ ET
0.969 0.537 0.290 rg BT /V8 1 Tf [<045F>] TJ ET
0.941 0.227 0.090 rg BT /V8 1 Tf [<0460>] TJ ET
\stoptyping

and in the reddish case (where we have a gray transparent color):

\starttyping[option=PDF]
2812 0 d0
0.400 0 0 rg 0.400 0 0 RG
BT /V8 1 Tf [<045B>] TJ ET
1 g 1 G /Tr1 gs
BT /V8 1 Tf [<045C>] TJ ET
BT /V8 1 Tf [<045D>] TJ ET
BT /V8 1 Tf [<045E>] TJ ET
BT /V8 1 Tf [<045F>] TJ ET
BT /V8 1 Tf [<0460>] TJ ET
\stoptyping

but this time we only get these verbose compositions once in the \PDF\ file. We
could optimize the last variant by a sequence of indices and negative kerns but
it hardly pays off. There is no need for \type {ActualText} here because we have
an entry in the \type {ToUnicode} vector:

\starttyping[option=PDF]
<C8> <D83DDC69>
\stoptyping

To be clear, the \type {/V8} is a sort of local reference to a font which can
have an \type {/F8} counterpart elsewhere. These \TYPETHREE\ fonts have their own
resource references and I found it more clear to use a different prefix in that
case. If we only use a few characters of this kind, of course the overhead of
extra fonts has a penalty but as soon we refer to more characters we gain a lot.

When we have \SVG\ fonts, the gain is a bit less. The \PDF\ resulting from the
\METAPOST\ run can of course be large but they are included only once. In \MKIV\
these would be (shared) so|-|called \type {XForm}s. In the page stream we then
see a simple reference to such an \type {XForm} but again wrapped into an \type
{ActualText}. In \LMTX\ we get just a reference to a \TYPETHREE\ character plus
of course an extra font.

The \typ {emojionecolor-svginot} font is somewhat problematic (although maybe in
the meantime it has become obsolete). As usual with new functionality,
specifications are not always available or complete (especially when they are
application specs turned into standards). This is also true with for instance
\SVG\ fonts. The current documentation on the \MICROSOFT\ website is reasonable
and explains how to deal with the viewport but when I first implemented support
for \SVG\ it was more trial and error. The original implementation in \CONTEXT\
used Inkscape to generate \PDF\ files with a tight bounding box and mix that with
information from the font (in \MKIV\ and the generic loader we still use this
method). This results in a reasonable placement for emoji (that often sit on top
of the baseline) but not for characters. More accurate treatment, using the
origin and bounding box, fail for graphics with bad viewports and strange
transform attributes. Now one can of course argue that I read the specs wrong,
but inconsistencies are hard to deal with. Even worse is that successive versions
of a font can demand different hacks. (I would not be surprised if some programs
have built|-|in heuristics for some fonts that apply fixes.) Here is an example:

\starttyping
<svg transform="translate(0 -1788) scale(2.048)" viewBox="0 0 64 64" ...>
    <path d="... all within the viewBox ..." ... />
</svg>
\stoptyping

It is no problem to scale up the image to normal dimensions, often 1000, or 2048
but I've also seen 512. The 2.048 suggests a 2048 unit approach, as does the 1788
shift. Now, we could scale up all dimensions by 1000/64 and then multiply by
2.048 and eventually shift over 1788, but why not scale the 1788 by 2.048 or
scale 64 by 2.048? Even if we can read the standard to suit this specification
it's just a bit too messy for my taste. In fact I tried all reasonable
combinations and didn't (yet) get the right result. In that case it's easier to
just discard the font. If a user complains that it (kind of) worked in the past,
a counter|-|argument can be that other (more recent) fonts don't work otherwise.
In the end we ended up with an option: when the \type {svg} feature value is
\type {fixdepth} the vertical position will be fixed.

\startbuffer[2a]
\definefontfeature[whatever][default][color=yes,svg=fixdepth]
\definefont[TestB][file:emojionecolor-svginot.ttf*whatever]
\stopbuffer

\typebuffer[2a][option=TEX] \getbuffer[2a]

\startbuffer[2b]
x{\TestB \char"1F41C \char"1F41B}x
\stopbuffer

\startlinecorrection
    \scale[height=1cm]{\getbuffer[2b]}
\stoplinecorrection

The newer \type {emojionecolor} font doesn't need this because it has a \type
{viewBox} of \type {0 54.4 64 64} which fixes the baseline.

\startbuffer[2c]
\definefontfeature[whatever][default][color=yes,svg=yes]
\definefont[TestB][file:emojionecolor.otf*whatever]
\stopbuffer

\typebuffer[2c][option=TEX] \getbuffer[2c]

\startlinecorrection
    \scale[height=1cm]{\getbuffer[2b]}
\stoplinecorrection

Another example of a pitfall is running into category one glyphs made from
several pieces that all have the same color. If that color is black, one starts
to wonder what is wrong. In the end the \CONTEXT\ code was doing the right thing
after all, and I would not be surprised if that glyph gets colors in an update of
the font. For that reason it makes no sense to include them as examples here.
After all, we can hardly complain about free fonts (and I'm also guilty of
imposing bugs on users). By the way, for the font referred to here (\type
{twemojimozilla}), another pitfall was that all shapes in my copy had a zero
bounding box which means that although a width is specified, rendering in
documents can give weird side effects. This can be corrected by the \type
{dimensions} feature that forces the ascender and descender values to be used.

\startbuffer[3a]
\definefontfeature[colored:x][default][colr=yes]
\definefontfeature[colored:y][default][colr=yes,dimensions={1,max,max}]
\definefont[TestC][file:twemojimozilla.ttf*colored:x]
\definefont[TestD][file:twemojimozilla.ttf*colored:y]
\stopbuffer

\typebuffer[3a][option=TEX] \getbuffer[3a]

\startbuffer[3b]
{\TestC\char 128028}\quad{\showglyphs\TestC\char 128028}\quad
{\TestD\char 128028}\quad{\showglyphs\TestD\char 128028}
\stopbuffer

\startlinecorrection
    \scale[height=2cm]{\getbuffer[3b]}
\stoplinecorrection

An example of a \PNG|-|enhanced font is the \type {applecoloremoji} font. The
bitmaps are relatively large for the quality they provide and some look like
scans.

\startbuffer[4a]
\definefontfeature[sbix][default][sbix=yes]
\definefont[TestE][file:applecoloremoji.ttc*sbix at 10bp]
\stopbuffer

\typebuffer[4a][option=TEX] \getbuffer[4a]

\startbuffer[4b]
\red \TestE \char 35 \char 9203 \char 9202
\stopbuffer

\startlinecorrection
    \scale[height=1cm]{\getbuffer[4b]}
\stoplinecorrection

As mentioned above, there are fonts that color characters other than emoji. We
give two examples (sometimes fonts are mentioned on the \CONTEXT\ mailing list).

\startbuffer[5a]
\definefontfeature
  [whatever]
  [default,color:svg]
  [script=latn,
   language=dflt]

\definefont[TestF][file:Abelone-FREE.otf*whatever          @ 13bp]
\definefont[TestG][file:Gilbert-ColorBoldPreview5*whatever @ 13bp]
\definefont[TestH][file:ColorTube-Regular*whatever         @ 13bp]
\stopbuffer

\typebuffer[5a][option=TEX] \getbuffer[5a]

Of course one can wonder about the readability of these fonts and unless one used
random colors (which bloats the file immensely) it might become boring, but
typically such fonts are only meant for special purposes.

\startbuffer[5b]
    {\TestF\setupinterlinespace[0.7]\input zapf \par}
\stopbuffer

\startbuffer[5c]
    {\TestG\setupinterlinespace     \input zapf \par}
\stopbuffer

\startbuffer[5d]
    {\TestH\setupinterlinespace[0.7]\input zapf \par}
\stopbuffer

\start \setupalign[tolerant] \getbuffer[5b] \stop

The previous font is the largest and as a consequence also puts some strain on
the viewer, especially when zooming in. But, because viewers cache \TYPETHREE\
shapes it's a one|-|time penalty.

\start \setupalign[tolerant] \getbuffer[5c] \stop

This font is rather lightweight. Contrary to what one might expect, there is no
transparency used (but of course we do support that when needed).

\start \setupalign[tolerant] \getbuffer[5d] \stop

This third example is again rather lightweight. Such fonts normally have a rather
limited repertoire although there are some accented characters included. But they
are not really meant for novels anyway. If you look closely you will also notice
that some characters are missing and kerning is suboptimal.

I considered testing some more fonts but when trying to download some interesting
looking ones I got a popup asking me for my email address in order to subscribe
me to something: a definite no|-|go.

%\section{\SVG\ to MetaPost}

I already mentioned that we have a built|-|in converter that goes from \SVG\ to
\METAPOST. Although this article deals with fonts, the following code
demonstrates that we can also access such graphics in \METAFUN\ itself. The nice
thing is that because we get pictures, they can be manipulated.

\startbuffer
\startMPcode{doublefun}
    picture p ; p := lmt_svg [ filename = "mozilla-svg-001.svg" ] ;
    numeric w ; w := bbwidth(p) ;
    draw p ;
    draw p xscaled -1 shifted (2.5*w,0);
    draw p rotatedaround(center p,45) shifted (3.0*w,0) ;
    draw image (
        for i within p : if filled i :
            draw pathpart i withcolor green ;
        fi endfor ;
    ) shifted (4.5*w,0);
    draw image (
        for i within p : if filled i :
            fill pathpart i withcolor red withtransparency (1,.25) ;
        fi endfor ;
    ) shifted (6*w,0);
\stopMPcode
\stopbuffer

\typebuffer[option=TEX]

This graphic is a copy from a glyph from an emoji font, so we have plenty of such
images to play with. The above manipulations result in:

\startlinecorrection
    \getbuffer
\stoplinecorrection

Now that we're working with \METAPOST\ we may as well see if we can also load a
specific glyph, and indeed this is possible.

\startbuffer[1]
\startMPcode{doublefun}
    picture lb, rb ;
    lb := lmt_svg [ fontname = "Gilbert-ColorBoldPreview5", unicode = 123 ] ;
    rb := lmt_svg [ fontname = "Gilbert-ColorBoldPreview5", unicode = 125 ] ;
    numeric dx ; dx := 1.25 * bbwidth(lb) ;
    draw lb ;
    draw rb shifted (dx,0) ;
    pickup pencircle scaled 2mm ;
    for i within lb :
        draw lmt_arrow [
            path        = pathpart i,
            pen         = "auto",
            alternative = "curved",
            penscale    = 8
        ]
            shifted (3dx,0)
            withcolor "darkblue"
            withtransparency (1,.5)
        ;
    endfor ;
    for i within rb :
        draw lmt_arrow [
            path        = pathpart i,
            pen         = "auto",
            alternative = "curved",
            penscale    = 8
        ]
            shifted (4dx,0)
            withcolor "darkred"
            withtransparency (1,.5)
        ;
    endfor ;
\stopMPcode
\stopbuffer

% Ok, I should make a macro ...

\startbuffer[2]
\startMPcode{doublefun}
    picture lb, rb ;
    lb := lmt_svg [ fontname = "Gilbert-ColorBoldPreview5", unicode = 42 ] ;
    rb := lmt_svg [ fontname = "Gilbert-ColorBoldPreview5", unicode = 64 ] ;
    numeric dx ; dx := 1.25 * bbwidth(lb) ;
    draw lb ;
    draw rb shifted (dx,0) ;
    pickup pencircle scaled 2mm ;
    for i within lb :
        draw lmt_arrow [
            path        = pathpart i,
            pen         = "auto",
            alternative = "curved",
            penscale    = 6
        ]
            shifted (3.5dx,0)
            withcolor "darkgreen"
            withtransparency (1,.5)
        ;
    endfor ;
    for i within rb :
        draw lmt_arrow [
            path        = pathpart i,
            pen         = "auto",
            alternative = "curved",
            penscale    = 6
        ]
            shifted (4.5dx,0)
            withcolor "darkyellow"
            withtransparency (1,.5)
        ;
    endfor ;
\stopMPcode
\stopbuffer

\typebuffer[1][option=TEX]

Here we first load two character shapes from a font. The \UNICODE\ slots (which
here are the same as the \ASCII\ slots) might look familiar: they indicate the
curly brace characters. We get two pictures and use the \type {within} loop to
run over the paths within these shapes. Each shape is made from three curves. As
a bonus a few more characters are shown.

\startlinecorrection
    \dontleavehmode
    \scale[height=3cm]{\getbuffer[1]}%
    \quad\quad\quad\quad
    \scale[height=3cm]{\getbuffer[2]}
\stoplinecorrection

It is not hard to imagine that a collection of such graphics could be made into a
font (at runtime). One only needs to find the motivation. Of course one can
always use a font editor (or Inkscape) and tweak there, which probably makes more
sense, but sometimes a bit of \METAPOST\ hackery is a nice distraction. Editing
the \SVG\ code directly is not that much fun. The overall structure often doesn't
look that bad (apart from often rather redundant grouping):

\starttyping[option=XML]
<svg xmlns="http://www.w3.org/2000/svg">
    <path fill="#d87512" d="..."/>
    <g fill="#bc600d">
        <path d="..."/>
    </g>
    <g fill="#d87512">
        <path d="..."/>
        <path d="..."/>
    </g>
    <g fill="#bc600d">
        <path d="..."/>
    </g>
    ...
</svg>
\stoptyping

In addition to \type {path}s there can be \type {line}, \type {circle} and
similar elements but often fonts just use the \type {path} element. This element
has a \type {d} attribute that holds a sequence of one character commands that
each can be followed by numbers. Here are the start characters of four such
attributes:

\starttyping
M11.585 43.742s.387 1.248.104 3.05c0 0 2.045-.466 1.898-2.27 ...
M53.33 39.37c0-4.484-35.622-4.484-35.622 0 0 10.16.05 ...
M42.645 56.04c1.688 2.02 9.275.043 10.504-2.28 5.01-9.482-.006 ...
M54.2 41.496s-.336 4.246-4.657 9.573c0 0 4.38-1.7 5.808-4.3 ...
\stoptyping

Indeed, numbers can be pasted together, also with the operators, which doesn't
help with seeing at a glance what happens. Probably the best reference can be
found at \typ {https://developer.mozilla.org/en-US/docs/Web/SVG} where it is
explained that a path can have move, line, curve, arc and other operators, as
well use absolute and relative coordinates. How that works is for another
article.

How would the \TEX\ world look like today if Don Knuth had made \METAFONT\
support colors? Of course one can argue that it is a bitmap font generator, but
in our case using high resolution bitmaps might even work out better. In the
example above the first text fragment uses a font that is very inefficient: it
overlays many circles in different colors with slight displacements. Here a
bitmap font would not only give similar effects but probably also be more
efficient in terms of storage as well as rendering. The \METAPOST\ successor does
support color and with \MPLIB\ in \LUATEX\ we can keep up quite well \unknown\ as
hopefully has been demonstrated here.


% It's no fun messing with these things that survive only for short time before
% being replaced by the next hyped fashion. Typical work than one needs to be paid
% for but never is.

\stopchapter

\stopcomponent