Hi,
Text rotation now works properly in d.labels for any justification
setting. Also placement is improved for all center and lower justified
text. Even multi-line labels are working correctly.
Only lightly tested so far.
For TrueType fonts you need to set the path to the font name in the
v.label step. (run-time override won't work anymore)
Hamish
On 06.04.2007 10:22, Hamish wrote:
Hi,
Text rotation now works properly in d.labels for any justification
setting. Also placement is improved for all center and lower justified
text. Even multi-line labels are working correctly.Only lightly tested so far.
I haven't tested multi-line labels, but rotation seems to work nicely.
There is however a bug. If there is a space between the ':' and the
label text, the space becomes part of the label and thus the label is
shifted to the right by one space. I have worked around this in
v.label.sa by not adding a space between the ':' and the label text.
I have also attached a patch which will add support for a label position
"none none", which simply means to place the label at the exact point
given (no shifting in any direction). So please test this together with
the newest version of v.label.sa in the cvs. I have not enabled
compilation on it automatically (yet), so you have to run make in
vector/v.label.sa before running make install.
In other words I'm looking for feedback on the performance of this
module, v.label.sa. Not the code (it is still a bit of a mess), but the
results. I'm especially interested if you find some odd behavior. It
should behave quite nicely... but you never know. I keep finding bugs...
For TrueType fonts you need to set the path to the font name in the
v.label step. (run-time override won't work anymore)
Yeah. This is a very nice addition. It works really well. Just what I
needed for my v.label.sa 
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
display~d.paint.labels~do_labels.c.diff (2.88 KB)
Hamish wrote:
> Text rotation now works properly in d.labels for any justification
> setting. Also placement is improved for all center and lower
> justified text. Even multi-line labels are working correctly.
>
> Only lightly tested so far.
Wolf wrote:
I haven't tested multi-line labels, but rotation seems to work nicely.
There is however a bug. If there is a space between the ':' and the
label text, the space becomes part of the label and thus the label is
shifted to the right by one space. I have worked around this in
v.label.sa by not adding a space between the ':' and the label text.
this is a bug in the rendering stage, not at the labels file creation
stage (there is nothing wrong with the labels file). Fixed last week in
d.labels/do_labels.c revs 1.20,1.21 with the improved rotation code.
ps.map was already working correctly.
I have also attached a patch which will add support for a label
position "none none", which simply means to place the label at the
exact point given (no shifting in any direction).
how does that differ from center,center (the default)? or is it "raw",
which is {R_move_abs(x,y); R_text(string);} in that case how does
none,none differ from the lower,left case?
(why is this useful?)
I just added some debug code in d.labels to write the rotated text
bounding boxes out to a vector ascii file. (zoom dependent, even with
size=mapunits, as the rendered font size is not smooth but jumps by
quantum amounts)
Hamish
(mostly off-line for the next few days)
On 17.04.2007 07:34, Hamish wrote:
Wolf wrote:
I haven't tested multi-line labels, but rotation seems to work nicely.
There is however a bug. If there is a space between the ':' and the
label text, the space becomes part of the label and thus the label is
shifted to the right by one space. I have worked around this in
v.label.sa by not adding a space between the ':' and the label text.this is a bug in the rendering stage, not at the labels file creation
stage (there is nothing wrong with the labels file). Fixed last week in
d.labels/do_labels.c revs 1.20,1.21 with the improved rotation code.
Yes, exactly as I said. However it isn't fixed (see attached screen
shots; with_space.png and without_space.png)
ps.map was already working correctly.
I haven't tested.
I have also attached a patch which will add support for a label
position "none none", which simply means to place the label at the
exact point given (no shifting in any direction).how does that differ from center,center (the default)? or is it "raw",
which is {R_move_abs(x,y); R_text(string);} in that case how does
none,none differ from the lower,left case?
(why is this useful?)
I want the lower left corner of the text should go exactly on the point
given in the labels file. center,center puts the center of the text, and
lower,left put the lower left, but with some magic adjustment. So I
guess it is sort of "raw". In v.label.sa I calculate the exact position
of a label and it may not be shifted, or else the algorithm doesn't hold.
If someone could just verify that the attached patch works, I can commit
it. (I have made it against the most recent CVS version)
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
display~d.paint.labels~do_labels.c.diff (2.47 KB)
> Wolf wrote:
>> I haven't tested multi-line labels, but rotation seems to work
>> nicely. There is however a bug. If there is a space between the ':'
>> and the label text, the space becomes part of the label and thus
>> the label is shifted to the right by one space. I have worked
>> around this in v.label.sa by not adding a space between the ':' and
>> the label text.
Hamish:
> this is a bug in the rendering stage, not at the labels file
> creation stage (there is nothing wrong with the labels file). Fixed
> last week in d.labels/do_labels.c revs 1.20,1.21 with the improved
> rotation code.Yes, exactly as I said. However it isn't fixed (see attached screen
shots; with_space.png and without_space.png)
sorry, I don't understand. Are Yichang and Kinmen supposed to be lined
up in those? Or are you saying that all text (regardless of multi-line)
are shifted +1 char to the right?
Can you create a labels file from spearfish's bugsites and edit the
labels file so one of the entries is like-
text: line of text1\nline of text 22\nline of text 333
then post the exact v.label command line + label entry to recreate the
bug?
or,
what does your text: entry look like for each of those screenshots?
text:Yichang\nKinmen
vs
text: Yichang\nKinmen
?
Perhaps only seen with TTF?
W:
>> I have also attached a patch which will add support for a label
>> position "none none", which simply means to place the label at the
>> exact point given (no shifting in any direction).
H:
> how does that differ from center,center (the default)? or is it
> "raw", which is {R_move_abs(x,y); R_text(string);} in that case how
> does none,none differ from the lower,left case?
> (why is this useful?)
W:
I want the lower left corner of the text should go exactly on the
point given in the labels file.
as given by the lower-left corner of the bounding box around the text,
or the lower-left corner of the first letter [or letter block] of text?
ps.map seems to justify the text directly on the edge of the bounding
box. d.labels currently pads a bit of space between the point and the
label, this extra space is by design. I think that the 1 space padding
before the start of the border box is nicer. Regardless, ps.map and
d.labels should try and do the same thing, be it padding or no padding.
With "none" are you trying to remove the padding from d.labels?
center,center puts the center of the
text, and lower,left put the lower left, but with some magic
adjustment. So I guess it is sort of "raw". In v.label.sa I calculate
the exact position of a label and it may not be shifted, or else the
algorithm doesn't hold.
(so it works? great!)
I think I will have to try .sa well to understand the problem properly.
Any spearfish maps which are a good example?
W:
If someone could just verify that the attached patch works, I can
commit it. (I have made it against the most recent CVS version)
I would like to understand the problem better before committing anything
to CVS. (ie be comfortable that we are not adding new features to work
around some shortcoming when we should be instead fixing that shortcoming
in the first place)
Unfortunately today I am short on time and capacity to help. :-/
Hamish
On 17.04.2007 09:52, Hamish wrote:
Wolf wrote:
I haven't tested multi-line labels, but rotation seems to work
nicely. There is however a bug. If there is a space between the ':'
and the label text, the space becomes part of the label and thus
the label is shifted to the right by one space. I have worked
around this in v.label.sa by not adding a space between the ':' and
the label text.Hamish:
this is a bug in the rendering stage, not at the labels file
creation stage (there is nothing wrong with the labels file). Fixed
last week in d.labels/do_labels.c revs 1.20,1.21 with the improved
rotation code.Yes, exactly as I said. However it isn't fixed (see attached screen
shots; with_space.png and without_space.png)sorry, I don't understand. Are Yichang and Kinmen supposed to be lined
up in those? Or are you saying that all text (regardless of multi-line)
are shifted +1 char to the right?
Exactly. Shifted +1 char to the right (by the width of a space character)
Can you create a labels file from spearfish's bugsites and edit the
labels file so one of the entries is like-
text: line of text1\nline of text 22\nline of text 333then post the exact v.label command line + label entry to recreate the
bug?
I use v.label.sa to generate the label files, and I'm quite sure there
is no bug in that (as it is basically a copy of what d.label does).
or,
what does your text: entry look like for each of those screenshots?
text:Yichang\nKinmen
vs
text: Yichang\nKinmen
?
Sorry, it was perhaps a bad example. Yichang and Kinmen are 2 labels,
and if you look at the two images you see that the first (with space) is
shifted to the right by one " " character. The with_space version has
label text like
text: Yichang
And the without_space has
text:Yichang
I have added another screen shot showing the label point and the label
text with and without space, and the effect of my patch to add none none
support.
Here is the labels file for these:
-------------------------------------------------------------------
east: 662726.716593
north: 4036029.863873
xoffset: -0.000000
yoffset: -0.000000
ref: lower left
font: /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf
color: green
size: 150.000000
width: 1
hcolor: none
hwidth: 0
background: none
border: none
opaque: yes
rotate: 0.000000
text: LL Space
east: 662726.716593
north: 4036029.863873
xoffset: -0.000000
yoffset: -0.000000
ref: lower left
font: /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf
color: blue
size: 150.000000
width: 1
hcolor: none
hwidth: 0
background: none
border: none
opaque: yes
rotate: 0.000000
text:LL No Space
east: 662726.716593
north: 4036029.863873
xoffset: -0.000000
yoffset: -0.000000
ref: none none
font: /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf
color: red
size: 150.000000
width: 1
hcolor: none
hwidth: 0
background: none
border: none
opaque: yes
rotate: 0.000000
text: N Space
east: 662726.716593
north: 4036029.863873
xoffset: -0.000000
yoffset: -0.000000
ref: none none
font: /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf
color: black
size: 150.000000
width: 1
hcolor: none
hwidth: 0
background: none
border: none
opaque: yes
rotate: 0.000000
text:N No Space
-------------------------------------------------------------------
The point is located at the north, east coordinates given in the label
file. I can live with the minimal shift which is probably due to cell
size or something. Note that all four labels have the same coordinates.
--Wolf
--
<:3 )---- Wolf Bergenheim ----( 8:>
