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

[Stephen Woodbridge]

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
>