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

[thomas bonfort]

On Tue, May 3, 2011 at 15:24, Lime, Steve D (DNR)
<steve.lime at state.mn.us> wrote:
> It's an interesting addition. Any of the other map engines support something
> like this?
After checking with Dane on irc, mapnik has this fallback option to.
http://trac.mapnik.org/wiki/FontSet

>
> 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.
That's a daunting task. The most complete (I think) font with
sufficient quality is the microsoft/ascender arialuni.ttf one, and it
costs $99 for a desktop license. Contact them if you need a quote for
a server license :)
Even that font is missing glyphs for some asian languages.

>
> 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.

The overhead would be negligible (add a for loop when looking for
glyphs, and order your fonts so that the most common glyphs are found
in the first font). in pseudo-code:

render(glyphidx):
   for font in fonts:
      glyph = font.lookup(glyphidx)
      if glyph:
         break
   ...

instead of what is done now:

render(glyphidx):
   glyph = font.lookup(glyphidx)
   ...



>
> 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.

yes, the mapscript setters would have to be updated, you're right.

>
> 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
>
>
>