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

[Lime, Steve D (DNR)]

It's an interesting addition. Any of the other map engines support something
like this?

Part of me says that creating a new font makes the most sense since more users
could make use of it using lots of software options- more bang for the buck. I've
no idea how big a task that is. If it were easy you'd probably see other fonts with
all the characters.

This is such a specific use case I think we'd need to make sure the effect is
negligible on normal use. Otherwise your proposal seems reasonable. The parsing
is straight forward, just split and trim spaces. Mapfile writing is also easy.

MapScript (as usual) presents a problem. You'd have to add a label->setFont() 
function that would replicate the mapfile parsing (split/trim) or skip that and
require use of update from string (e.g. "LABEL 'font1,font2,font3'"). It's probably
not worth worrying about.

Steve

________________________________________
From: mapserver-dev-bounces at lists.osgeo.org [mapserver-dev-bounces at lists.osgeo.org] On Behalf Of thomas bonfort [thomas.bonfort at gmail.com]
Sent: Sunday, May 01, 2011 1:02 PM
To: MapServer Dev Mailing List
Subject: [mapserver-dev] fallback font(s) for labels : pre RFC draft

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
_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-dev