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

Wed May 4 15:27:23 EDT 2011

I'm fine with that also. the other use-cases incur a significant
amount of bloat, and would only be scarcely used.

On Wed, May 4, 2011 at 20:59, Stephen Woodbridge
<woodbri at swoodbridge.com> wrote:
> On 5/4/2011 2:51 PM, Lime, Steve D (DNR) wrote:
>>
>> I’d propose:
>>
>>   # single fonts
>>   FONT "arial"
>>
>>   # font lists
>>   FONT "arabic-eg,arialuni"
>>
>>   # binding (could be strings of either form listed above)
>>   FONT [font]
>>
>> That's it. No binding within a list...
>
> This would work for me. I knew the other form would be be problematic but
> this is a very suitable compromise.
>
> -Steve W
>
>> Steve
>>
>> -----Original Message-----
>> From: mapserver-dev-bounces at lists.osgeo.org
>> [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Stephen
>> Woodbridge
>> Sent: Wednesday, May 04, 2011 1:29 PM
>> To: mapserver-dev at lists.osgeo.org
>> Subject: Re: [mapserver-dev] fallback font(s) for labels : pre RFC draft
>>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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
>