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 ?