Open tbonfort opened 12 years ago
Author: sdlime Date: 2005/08/31 - 18:22
*** Bug 1425 has been marked as a duplicate of this bug. ***
Author: sdlime Date: 2005/08/31 - 18:23
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
Author: sdlime Date: 2005/08/31 - 20:35
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
Author: gis@oi.nu Date: 2005/09/02 - 06:11
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)
Author: sdlime Date: 2006/01/12 - 07:03
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
Author: sdlime Date: 2006/01/16 - 21:53
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
Date: 2007/11/07 - 17:15 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 ?
Author: sdlime Date: 2007/11/08 - 00:31 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
Author: sdlime Date: 2007/11/08 - 06:16 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
Date: 2008/09/26 - 16:31 fixed in 2013bbb94e1273e801b8b13c71206fbab0f9a669 (r7928)
as Steve suggested, we now adjust the baseline by only looking at the first line in the case of multiline text
Date: 2012/03/14 - 14:31
in f3a6f8f7ce31493b57a6f7d97bc951fe47d32fec (r13245) and c3f1ff0cc5c1e57ebf94b723d81b30c491ea446e (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.
Reporter: gis@oi.nu Date: 2005/08/31 - 18:05