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

Thu May 5 09:14:33 EDT 2011

I've got an initial implementation working.
compared to what initialy thought, there is no change in the labelObj
object, so mapscript won't have to be changed, and there won't have to
be any changes to the binding code.

an area which I had overlooked is that the renderer getTrueTypeBox had
to be changed a bit  so that they accept a list of fonts rather than a
single font.

I'll put this on hold until the 6.0 release and will write a quick rfc then.

--
thomas

On Wed, May 4, 2011 at 21:27, thomas bonfort <thomas.bonfort at gmail.com> wrote:
> 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
>>
>