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

[Stephen Woodbridge]

Thomas,

As we have discussed off list, I think this is a great idea. In doing a 
little research into available fonts, I get the sense that there is a 
move away from creating pan-world unicode fonts because they while they 
give you wide coverage, it is not always good coverage. One example 
sited if Arabic and the fact that Egyptian Arabic glyphs are different 
from those used in say Farsi and some other areas.

By supporting multiple fonts, it would be good if one or more of the 
fonts in the list could be attribute [font] substitution fields. This 
way a preferred font of a given label could be captured in an attribute 
column and then more generalized could be used for other qlyphs.

+1 on this idea

-Steve W

On 5/1/2011 2:02 PM, thomas bonfort wrote:
> 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