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

Daniel Morissette dmorissette at mapgears.com
Wed May 4 13:54:56 EDT 2011


For the record, I don't have a strong opinion (since I don't have that 
need at the moment), but this sounds like a good idea to solve this 
problem, as long as there is no impact on performance.

Daniel

On 11-05-04 12:05 AM, Stephen Woodbridge wrote:
> 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
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev


-- 
Daniel Morissette
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000



More information about the mapserver-dev mailing list