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

Wed Dec 7 13:44:53 EST 2011

Thomas Jacobi (irc:fake) revived this issue and made the necessary
changes to adapt the functionality across all renderers.

We now have an rfc up for review here:
http://trac.osgeo.org/mapserver/browser/trunk/docs/en/development/rfc/ms-rfc-80.txt

I think the only potential controversial issue is the harcoded number
of fallback fonts that is set to 5. That number should be sufficient
for the majority of use cases, and avoids the use of additional calls
to malloc which would have slightly impacted performance for people
not using fallback fonts.

As this has already been discussed in this thread, I will call for
vote for this tomorrow or after tomorrow if no additional issues are
raised here.

best regards,

thomas

On Thu, May 5, 2011 at 15:14, thomas bonfort <thomas.bonfort at gmail.com> wrote:
> 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
>>>
>>