Badly placed labels with the characters "gjpqy"

[aboudreault]

It seems that a label that contains a letters within "gjpqy" (letters with tail) are not placed correctly. They are moved too high. It's probably due to the way we calculate the label position.

I will attach images to demonstrate the bug. I created a mapfile with 2 layers with a simple WKT feature. Both feature are points and they have the same latitude value but a different longitude value.

[aboudreault]

Steve, Thomas, do you have any objection if I investigate to fix this bug for 6.0 release? I would like to be sure it wont be any bad behaviors or something I didn't think about...

[sdlime]

Ah, baseline issues. I suppose it's ok to investigate if you have time. I think the label placement is renderer independent isn't it Thomas?

What does 5.6 produce? If similar than I wouldn't rush to get this into 6.0..

Steve

[tbonfort]

+1 for waiting till after 6.0 if this isn't a regression

[tbonfort]

see also #1449, where I still don't understand what we're trying to do with lines around line 2446 of mapdraw.c: ​http://trac.osgeo.org/mapserver/browser/trunk/mapserver/mapdraw.c?rev=11482#L2446

from some testing I've done, msGetLabelSize will return a rectObj with maxy>0 if the given text has some characters where parts will end up below the baseline. I'm guessing we should take that into account when calculating the labelpoint rather than relying on the current hack of setting labelPtr->offsety.

Steve any comments, as you seem to be the one who knows about baseline adjustments?

[aboudreault]

We did some investigation into that issue. The main problem is that agg/gd (that uses freetype) compute a label bbox based on the letter that the string contains. So, obviously, a string like "aaa", wont be the same than "apa". It is not especially a bug in MapServer since we return the minimal bbox of a string, which is ok. However, for our client, we did a patch in AGG, to always use the ascender/descender of a freetype font in the text bbox. That way, all bbox returned have always the same y1,y2 values. This is not a solution for our mapserver users. Perhaps in the future we could add a mapserver option to do something similar.

[sdlime]

We really need the full bbox for collision avoidance, but could alter label point computation using ascender, descender and perhaps even caps height depending on label position. I would call it a MapServer bug.

For UL/UR/UC you'd want to add the descender height pulling the labels down (in graphics coords). For the CL/CR/CC you'd want to center on the full height. For LL/LR/LC you'd want to subtract the ascender height pulling the labels up a bit.

Alan, where'd you do your hacking? Seems like this would be in the get_metrics function(s) in maplabel.c.

Steve

[aboudreault]

In the get_metrics function, we already have the string bbox computed, so we cannot know the ascender/descender values of the font. It has been obtained via agg/gd. I did my change in renderers/agg/src/agg_font_freetype.cpp, in the prepare_glyph function.

[tbonfort]

Alan,

isn't rect.maxy>0 an indication of how low you are below the baseline ? (ok, it probably won't work for multiline labels)

[aboudreault]

Yes Thomas, this is an indication. IIRC, the get_metrics* functions are called for each annotation to be drawn (sequentially). So if the text is "aaa", we won't know anything about what the ascender/descender are. So we can't adjust the values. However, we can know the descender If we have a text "apa", since the p will have a bbox miny<0. I may be wrong on that... you both probably know more than me about text rendering. But since we have the bbox computed in those functions, I don't see how we could adjust things properly considering *all* strings and drawing features sequentially. Of course, we could modify the API to be able to get the ascender/descender of the font easily to adjust our text placement. Though I don't think this is a 6.0 task.

[tbonfort]

in r13245 and r13250 I have removed the hack to adjust the baseline, the renderers now return a bounding box where the ink under the baseline of the last line is not accounted for in the bounding box. This makes for nicer output when labeling markers, as the label text gets put closer to the marker. The only case with latin characters that might cause a tiny collision is if the last character of the label is a q *and* the last line is the longest one (which is always the case on single line labels). I feel the benefits largely outweigh the inconvenience. With the applied patch, this test-case passes without the need for patching AGG.

[tbonfort]

msautotest added in 13251

[tbonfort]

msautotest added in r13251

[dmorissette]

aboudreault, can you please confirm that this change does not "break" anything with MapInfo labels coming as STYLEITEM AUTO which was the original problem that was reported to us and led to the current ticket?