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

Stephen Woodbridge woodbri at swoodbridge.com
Wed May 4 14:29:00 EDT 2011


Daniel,

I raised the issue of potential performance impacts with Thomas offlist. 
Thomas' proposed implementation is I think sound. The reason in that if 
you have a list of fonts to search and the glyph is found in the first 
font, then it is no more costly than that what exists today.

Obviously if one puts a long list of fonts in play and you have to 
search multiple fonts to find a glyph, then it sill be costly. I think 
this is penalty for stupidity :)

It might be possible to have the list in the fontset.txt file but I 
think that this would be a bad idea, the lists need to be applied at the 
label level, because it is here (or in the layer) that you know what are 
the possible fonts needed to render this particular data source.

I also think it would be wise and efficient to allow attribute binding 
to the FONT tag in the label so an individual object can also specify 
what font is required to render it. This might impact the parsing of a 
font list on the FONT tag like:

# single fonts
FONT "arial"
FONT [font]

# font lists
FONT "arabic-eg" "arialuni"
FONT [font] "arialuni"

Can you have multiple fonts listed inside [font]?
FONT [font] # multiple fonts listed in attibute.

-Steve


On 5/4/2011 1:54 PM, Daniel Morissette wrote:
> 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
>
>



More information about the mapserver-dev mailing list