[mapserver-dev] fallback font(s) for labels : pre RFC draft

[thomas bonfort]

In my recent geekings with openstreetmap data rendered with mapserver
( http://www2.terriscope.fr/geocache/demo/wmts?layers=00000B ) I came
across an issue that could involve some mapserver enhancements:

The openstreetmap dataset contains labels (utf8 encoded) that span the
full unicode spectrum, i.e. latin, arabic, CJK, etc... but there is no
single font that contains the glyphs for all unicode codepoints (aside
from unifont.ttf, but that one tends to render rather poorly). As a
consequence, there is no way of rendering all label names across the
planet without some labels showing up as the well-known empty box.

Overcoming this situation would mean either creating a nice font with
all the unicode glyphs contained in it, or to modify mapserver so each
labelObj is given a list of fonts rather than a single font. For each
glyph, the renderer would open, in order, the fonts supplied to the
label, and stop whenever the current font supports that glyph.

In terms of performance overhead, this would be negligible for people
still using a single font in their label. When using multiple fonts,
there would be an overhead as multiple font files have to be opened if
the first one does not contain the glyph (all the renderers have a
cache in place to alleviate that).

In terms of backwards compatibility, supposing we chose to go the way
of a parser that recognizes FONT font1,font2,font3, people who have
chosen to name their fontset key with a comma will encounter failed
text rendering, but I don't think that's a very common syntax.

In terms of code modification, labelObj would be changed so that font
is an array of char arrays (char**) instead of a char array (char*),
and the individual renderers would have to be updated so they know
they have to open each given font in turn in case a glyph was not
found.

I'd be happy to hear any other ideas or comments on the question, RFC
to follow if this seems like a good idea.

regards,
thomas