label wrap and centering

[thomas bonfort]

Steve and Steve ;), thanks for the insights. comments inline

On Nov 30, 2007 5:15 AM, Steve Lime <Steve.Lime at dnr.state.mn.us> wrote:
> Alignment would be a great addition. I had it working ok years ago when MapServer had
> native freetype support, but pulled it when GD added it. A small price to pay. I think I'd just
> go with 'ALIGN' as we might be able to reuse the keyword elsewhere, although perhaps being
> explicit is better. Are you talking about AGG only or would this apply to GD as well?

The way I proposed is renderer-independant, as the processing of the
text would take place at the beginning of msDrawShape, with a call to
msTransformLabelText. I added and use this function to take the text
processing out of the renderers (for the time being only ENCODING and
WRAP are treated, but my local modifications are there too). But that
way of doing is a compromise between maintainance facility and
flexibility, i.e. text centering can't be done perfectly easily that
way.

>
>
> On the wrapping, I wonder if this is limited to just wrapping. For example, we could define a
> new parameter called MAXLENGTH and behave a couple of ways:
>
> 1) if WRAP is set to a character or string do as you propose
> 2) if WRAP is set to AUTO (this would be new) then we automatically add a newline every
> MAXLENGTH characters. Might be able to do some funky labeling with that, for instance a
> string of 123 with MAXLENGTH 1 would be rendered as:
>
> 1
> 2
> 3
>
> just an idea, but this would allow splitting not possible with WRAP
>
> 3) if no WRAP is set and MAXLENGTH is set (default would be -1?) then we would skip
> that label. The only way to do that now is using a length([item]) expression and this would be
> faster.
>
> 4) if MAXLENGTH isn't set then we behave just as we do now

> [....]


I like the idea. This would mean we don't go the way of MINWRAPLENGTH
as I proposed, as it makes little sense to keep the trivial solution
in that case. The only drawback to MAXLENGTH I'd see is that it allows
very short lines, which imo are uglier than the occasional "too long"
line that you get with MINWRAPLENGTH:

MAXLENGTH:
"this might be
a
verylongword"

MINWRAPLENGTH:
"this might be
a verylongword"

> I think you have to keep long words together even if the are greater the MAXLENGTH.
> Or we could set MAXLENGTH -4 to imply hard wrapping which would split words like [..]

I'd agree with Steve2 that you'd have to use  a negative value to
force "hard" wrapping which breaks words. In that case I don't think
we need a WRAP AUTO, the "space" character should be sufficient, as if
MAXLENGTH is negative we don't need a wrap parameter, and if not WRAP
AUTO is identical to WRAP ' '

> I also think that it would be good to add ALIGN support for this. It
> might make sense to require each renderer to support a function that
> passes a string and whatever info is needed, and returns the rendered
> string length or an approximation of it. This way it could be added to
> vtable and alignment calculation could be done outside the renderer.

string length is already a function that I proposed should go into the
vtable. That could be generic solution that would allow rather precise
centering and still use space characters for padding:
- have the renderer compute and cache the size of two successive
"spaces" (to account for kerning)
- then for each line, compute the size of the line and padd with the
appropriate number of spaces.
This should work, I'm just a little nervous about the performance
penalty. Although it would only kick in if ALIGN CENTER or RIGHT was
specified.



Shall I write an RFC for this?

thomas