Alignment of TrueType label is not beautiful.

[gis@…]

In the label display processing, the position has been
decided based on the rectangle obtained by GD. 

there is no problem when the character string is usually 
displayed. 
but, When the character string is displayed by one character
one point, it is not so good.

I wrote the explanation patch. 
--------------------------------
*** maplabel.c.org	2005-08-31 15:09:05.114273793 +0900
--- maplabel.c	2005-08-31 15:03:29.600871424 +0900
***************
*** 313,318 ****
--- 313,323 ----
      rect->miny = bbox[5];
      rect->maxx = bbox[2];
      rect->maxy = bbox[1];
+ 
+     // baseline shifting. quick fix.
+     label->offsety += MS_NINT((((bbox[5] + bbox[1])) + size) / 2);
+     label->offsetx += MS_NINT((bbox[0] / 2));  // optional.
+ 
  #else
      msSetError(MS_TTFERR, "TrueType font support is not 
available.", "msGetLabelSize()");
      return(-1);
--------------------------------
I think that this is not so good solution. accuracy is bad. 

IMHO, we would make align method can chosen by the POSITION
parameter of MapFile to make it not influence an existing user. 

----------------------------------------------------------
sample images are here.

(1) displayed by Mapserver 4.6.1 bitmap font
http://oi.nu/msbugzilla/hollywood_ms_bitmap.png

(2) displayed by Mapserver 4.6.1 truetype font
http://oi.nu/msbugzilla/hollywood_ms_truetype.png

(3) displayed by Mapserver 4.6.1 truetype font. patch applied.
http://oi.nu/msbugzilla/hollywood_ms_tt_patched.png

(4) displayed by ESRI ArcMap8 truetype font.
http://oi.nu/msbugzilla/HOLLYWOOD_ArcMap.gif

# I'm not good at english. sorry.
--
IIDA Tetsushi.(hogeman)

[sdlime]

*** Bug 1425 has been marked as a duplicate of this bug. ***

[sdlime]

Good deal, thanks for investigating. There was another similar bug to this but 
without the patch. I'll apply the patch to 4.7 and folks can test there. Then 
we can back port to 4.6.2...

Steve

[sdlime]

I've applied the patch in 4.7. I'm wondering if the y offset should be even 
more. In your example the 'y' is still a bit high...

Steve

[gis@…]

I know it's not a good solution.
but it's better than original.

The code that I posted is corrected by the guess from the
rectangle and the font point. and the processing position is
too late, it is rounding to int. 
I don't think that the number of pixels for an actual 
BoundingBox is so corresponding to the number of points
currently used to calculation. 

I think that the major alteration is considerably needed
when it tries to do drawing that uses correct font metrics. 
--
IIDA Tetsushi(hogeman)

[sdlime]

Ok, this fix has a bad side affect. Repeated calls to msGetLabelSize with the
same labelObj results in cummulative changes to the label offset parameter. This
is OK when working through the cache because each piece of text has its own
labelObj (since angle and size can vary by feature), but outside the label
cache, particularly with image legends that offset is very visible.

Couple of solutions:

  - make offset computation option by adding a boolean function parameter
  - rollback this patch

I'm not positive that adding a parameter will work, but would consider trying.
Thoughts?

Steve

[sdlime]

Ok, for now I have added another parameter to trigger the baseline offset
computation. It's ok to do in the context of a label cache but not in other
instances. Ideally we probably should just have another function to compute that
but this will do for now. May change later on in 4.9/10. No big deal since this
is not forward facing functionality at all.

Steve

[tbonfort]

this patch is usefull when using multiple single character labels that put together represent a whole word right ?

there's a flaw in this way of doing this, as as soon as the label is a multiline label, the whole label is offset vertically further and further away from the label point as the numer of lines increases.

is this way of using labels still usefull now that we have label follow ?

[sdlime]

This way of doing labels (with a specific angle) is still useful. The follow case falls back to this in a number of instances. I thought I backed the patch out at one point because of exactly the problem you describe.

Steve

[sdlime]

Ah, now I see what I did. The legend code was exhibiting that same vertical offset problem you're seeing. Hence the addition of the adjustBaseline parameter. The label object in a legend was being re-used so the offset changes were cumulative. Different issue then you're referring to.

But, now looking at the code it is assuming a single line of text and in the case of multi-line text the bbox is too big so the offset is wrong. Argh...

We can't just not compute the offset for multi-line labels. If mixed with single-line labels the base offset would be different and things would never align.

What about using just the first line in a multi-line label? That should give a proper bbox to compute the baseline offsets. The x offset is based on the minx so the length doesn't matter.

Steve

[tbonfort]

fixed in r7928

as Steve suggested, we now adjust the baseline by only looking at the first line in the case of multiline text

[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. There was no test-case attached to this ticket so I cannot guarantee that this particular case remains correct, although I would think so. Plus, now we have angle follow labels, I think the usage of labelling a single character on successive points is an unneeded use-case.