Great job on this feature!
But not working for me. I have a label with 108 characters and it's still
rendered on the same line, no
wrapping.
i edited geoserver web.xml (tested on geoserver map preview) with
<context-param>
<param-name>USE_NG_LABELLER</param-name>
<param-value>true</param-value>
</context-param>
added to the sld textsymbolizer
<VendorOption name="followLine">true</VendorOption>
although i'm not expecting curved line labeling. this is a point.
something missing?
question:
It is said "if the label exceeds a certain length it will be wrapped on
multiple lines", is this length parametrized somewhere? what's the minimun
character length value to force label wrapping?
thanks on advance.
Pedro Mendes
--
View this message in context: http://www.nabble.com/Automatic-Label-Wrapping-(Throw-GeoServer-a-curve)-tp21376062p21376062.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
Pedro Mendes ha scritto:
Great job on this feature!
But not working for me. I have a label with 108 characters and it's still
rendered on the same line, no wrapping.
i edited geoserver web.xml (tested on geoserver map preview) with <context-param>
<param-name>USE_NG_LABELLER</param-name>
<param-value>true</param-value>
</context-param>
added to the sld textsymbolizer <VendorOption name="followLine">true</VendorOption> although i'm not expecting curved line labeling. this is a point.
That param only enables curved labels on lines.
For auto wrapping, the param is another:
<VendorOption name="autoWrap">100</VendorOption>
The new labeller actually has many more parameters you can
play with, hopefully they will be documented soon.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea, thanks for the tip it works just fine!
A doubt: the wrapping value is in pixels so string character length or an
character sequence like '\n' are not consider?
Looking forward for the documention!
Pedro Mendes
Andrea Aime-4 wrote:
Pedro Mendes ha scritto:
Great job on this feature!
But not working for me. I have a label with 108 characters and it's still
rendered on the same line, no
wrapping.
i edited geoserver web.xml (tested on geoserver map preview) with
<context-param>
<param-name>USE_NG_LABELLER</param-name>
<param-value>true</param-value>
</context-param>
added to the sld textsymbolizer
<VendorOption name="followLine">true</VendorOption>
although i'm not expecting curved line labeling. this is a point.
That param only enables curved labels on lines.
For auto wrapping, the param is another:
<VendorOption name="autoWrap">100</VendorOption>
The new labeller actually has many more parameters you can
play with, hopefully they will be documented soon.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
View this message in context: http://www.nabble.com/Automatic-Label-Wrapping-(Throw-GeoServer-a-curve)-tp21376062p21376940.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
Pedro Mendes ha scritto:
Andrea, thanks for the tip it works just fine!
A doubt: the wrapping value is in pixels so string character length or an
character sequence like '\n' are not consider?
String character length is ignored, the Java built in word wrapper,
that is supposed to work with various scripts, uses pixels only for
word wrapping.
A \n is considered and should result in a line break instead.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
\n isn´t putting new lines on label.. =( This is my goal. This line break
issue was already target of discussion here but I must refer is importance
on labelling issues.
testing string: 123\n456\n7890.Some geotools logs:
2009-01-09 18:17:21,254 TRACE [org.geotools.filter] - kid 0 [#text:
123\n456\n7890]
2009-01-09 18:17:21,254 DEBUG [org.geotools.filter] - processing
123\n456\n7890
2009-01-09 18:17:21,254 DEBUG [org.geotools.filter] - made new logic factory
2009-01-09 18:17:21,254 DEBUG [org.geotools.filter] - parsingExpression null
2009-01-09 18:17:21,254 DEBUG [org.geotools.filter] - processing root null
2009-01-09 18:17:21,254 DEBUG [org.geotools.filter] - processing literal
[literal: null]
2009-01-09 18:17:21,254 TRACE [org.geotools.filter] - literal elements (1)
[literal: null]
2009-01-09 18:17:21,254 TRACE [org.geotools.filter] - kid 0 [#text:
]
2009-01-09 18:17:21,254 TRACE [org.geotools.filter] - empty text element
2009-01-09 18:17:21,254 DEBUG [org.geotools.filter] - made new logic factory
2009-01-09 18:17:21,254 DEBUG [org.geotools.filter] - parsingExpression null
2009-01-09 18:17:21,254 DEBUG [org.geotools.filter] - processing root null
2009-01-09 18:17:21,254 DEBUG [org.geotools.filter] - processing literal
[literal: null]
2009-01-09 18:17:21,254 TRACE [org.geotools.filter] - literal elements (1)
[literal: null]
2009-01-09 18:17:21,254 TRACE [org.geotools.filter] - kid 0 [#text: Arial]
Cumps,
Pedro Mendes
Andrea Aime-4 wrote:
Pedro Mendes ha scritto:
Andrea, thanks for the tip it works just fine!
A doubt: the wrapping value is in pixels so string character length or an
character sequence like '\n' are not consider?
String character length is ignored, the Java built in word wrapper,
that is supposed to work with various scripts, uses pixels only for
word wrapping.
A \n is considered and should result in a line break instead.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
View this message in context: http://www.nabble.com/Automatic-Label-Wrapping-(Throw-GeoServer-a-curve)-tp21376062p21377805.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
Pedro Mendes ha scritto:
\n isn´t putting new lines on label.. =( This is my goal. This line break
issue was already target of discussion here but I must refer is importance
on labelling issues.
How did you specify the newlines? SLD is setup, by schema, to
eat all the newlines you specify as literals: white space conservation
policy is "collapse", which means all subsequent spaces, including
newlines, will be turned into a single space (that's how OGC wrote it).
Gabriel suggested to use a CDATA section to keep the newlines and
did some work on the topic. Gabriel, can you shed some light on this?
Alternative to a CDATA section, we could create a "newline" filter function.
If the newline is inside your data (that is, in the database,
shapefile, whatever) it should work. If now, do you have a sample
sld and data to reproduce the issue?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea, your new labeller uses TextLayout, right?
if so it'd be a good time to apply the patch at
<http://jira.codehaus.org/browse/GEOT-1996>, which adds CDATA section support
to SLDParser.
I didn't apply it yet waiting for the labeller to be ready to handle multiline
labels, but with that patch the expressions hit the labeller with any fancy
stuff you may want to put into a cdata section, and since SLD uses mixed syntax
for cssparameter you can buld the label you want with a combination of
expressions and literals.
hope that helps,
Gabriel
On Friday 09 January 2009 17:42:30 Andrea Aime wrote:
Pedro Mendes ha scritto:
> \n isn´t putting new lines on label.. =( This is my goal. This line break
> issue was already target of discussion here but I must refer is
> importance on labelling issues.
How did you specify the newlines? SLD is setup, by schema, to
eat all the newlines you specify as literals: white space conservation
policy is "collapse", which means all subsequent spaces, including
newlines, will be turned into a single space (that's how OGC wrote it).
Gabriel suggested to use a CDATA section to keep the newlines and
did some work on the topic. Gabriel, can you shed some light on this?
Alternative to a CDATA section, we could create a "newline" filter
function.
If the newline is inside your data (that is, in the database,
shapefile, whatever) it should work. If now, do you have a sample
sld and data to reproduce the issue?
Cheers
Andrea
The data is in the database. Strings with multiple lines are stores in
following format 'ABC\nDEF\nGH'...
It's specified in the sld something like
<Label>
<ogc:PropertyName>CAPTION</ogc:PropertyName>
<Label>
I expect to get a label on the map like
ABC
DEF
GH
with the text justify.
I read Gabriel response to this post. So in this moment, without the patch
Gabriel talked about ins't possible to achieve multiple lines with some
character(s) or something besides the autoWrapping in pixels of the new
labeller, i'm right?
Cumps,
Pedro Mendes
sld snippet:
<Rule>
<MinScaleDenominator>3406</MinScaleDenominator>
<MaxScaleDenominator>5040</MaxScaleDenominator>
<TextSymbolizer>
<Label>
<ogc:PropertyName>CAPTION</ogc:PropertyName>
</Label>
<CssParameter name="font-family">Arial</CssParameter>
<CssParameter name="font-size">
<ogc:Literal>6</ogc:Literal>
</CssParameter>
<LabelPlacement>
<PointPlacement>
<AnchorPoint>
<AnchorPointX>0.5</AnchorPointX>
<AnchorPointY>0.5</AnchorPointY>
</AnchorPoint>
</PointPlacement>
</LabelPlacement>
<Halo>
<Radius>
<ogc:Literal>1</ogc:Literal>
</Radius>
<Fill>
<CssParameter name="fill">#FFFFFF</CssParameter>
<CssParameter name="fill-opacity">0.85</CssParameter>
</Fill>
</Halo>
<Fill>
<CssParameter name="fill">
<ogc:PropertyName>COLOR</ogc:PropertyName>
</CssParameter>
</Fill>
</TextSymbolizer>
</Rule>
Andrea Aime-4 wrote:
Pedro Mendes ha scritto:
\n isn´t putting new lines on label.. =( This is my goal. This line break
issue was already target of discussion here but I must refer is
importance
on labelling issues.
How did you specify the newlines? SLD is setup, by schema, to
eat all the newlines you specify as literals: white space conservation
policy is "collapse", which means all subsequent spaces, including
newlines, will be turned into a single space (that's how OGC wrote it).
Gabriel suggested to use a CDATA section to keep the newlines and
did some work on the topic. Gabriel, can you shed some light on this?
Alternative to a CDATA section, we could create a "newline" filter
function.
If the newline is inside your data (that is, in the database,
shapefile, whatever) it should work. If now, do you have a sample
sld and data to reproduce the issue?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
View this message in context: http://www.nabble.com/Automatic-Label-Wrapping-(Throw-GeoServer-a-curve)-tp21376062p21415580.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
Pedro Mendes ha scritto:
The data is in the database. Strings with multiple lines are stores in
following format 'ABC\nDEF\nGH'...
It's specified in the sld something like
<Label>
<ogc:PropertyName>CAPTION</ogc:PropertyName>
<Label>
I expect to get a label on the map like
ABC
DEF
GH
with the text justify.
I read Gabriel response to this post. So in this moment, without the patch
Gabriel talked about ins't possible to achieve multiple lines with some
character(s) or something besides the autoWrapping in pixels of the new
labeller, i'm right?
Nope, it should work fine instead, something is going on in the labeller, there's a bug, this is not expected.
Gabriel patch is about specifying newlines in the <Label> when
chaining multiple attributes, something like:
<Label>
<ogc:PropertyName>NAME</ogc:PropertyName> <![CDATA[
]]> <ogc:PropertyName>SURNAME</ogc:PropertyName>
<Label>
in order to put name and surname on two different lines (the standard
parsing will eat the newline and just put a single space between
name and surname).
Can you share your SLD and sample data with me so that I can
reproduce the issue? (private mail is fine, I won't divulge your data).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea thanks for fast reply. Here it is the sld
http://www.nabble.com/file/p21416162/sld_caption.sld sld_caption.sld
The data is irrelevant because i'm testing putting a string like
'123\n456\n7890' directly in the sld element Label..I think it should be the
same having
<Label>
<ogc:Literal>123\n456\n7890</ogc:Literal>
<Label>
and
<Label>
<ogc:PropertyName>CAPTION</ogc:PropertyName>
<Label>
where CAPTION column holds value 123\n456\n7890... Am I correct?
Andrea Aime-4 wrote:
Pedro Mendes ha scritto:
The data is in the database. Strings with multiple lines are stores in
following format 'ABC\nDEF\nGH'...
It's specified in the sld something like
<Label>
<ogc:PropertyName>CAPTION</ogc:PropertyName>
<Label>
I expect to get a label on the map like
ABC
DEF
GH
with the text justify.
I read Gabriel response to this post. So in this moment, without the
patch
Gabriel talked about ins't possible to achieve multiple lines with some
character(s) or something besides the autoWrapping in pixels of the new
labeller, i'm right?
Nope, it should work fine instead, something is going on in the
labeller, there's a bug, this is not expected.
Gabriel patch is about specifying newlines in the <Label> when
chaining multiple attributes, something like:
<Label>
<ogc:PropertyName>NAME</ogc:PropertyName> <![CDATA[
]]> <ogc:PropertyName>SURNAME</ogc:PropertyName>
<Label>
in order to put name and surname on two different lines (the standard
parsing will eat the newline and just put a single space between
name and surname).
Can you share your SLD and sample data with me so that I can
reproduce the issue? (private mail is fine, I won't divulge your data).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
View this message in context: http://www.nabble.com/Automatic-Label-Wrapping-(Throw-GeoServer-a-curve)-tp21376062p21416162.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
Pedro Mendes ha scritto:
Andrea thanks for fast reply. Here it is the sld http://www.nabble.com/file/p21416162/sld_caption.sld sld_caption.sld The data is irrelevant because i'm testing putting a string like
'123\n456\n7890' directly in the sld element Label..I think it should be the
same having
<Label>
<ogc:Literal>123\n456\n7890</ogc:Literal>
<Label>
and
<Label>
<ogc:PropertyName>CAPTION</ogc:PropertyName>
<Label>
where CAPTION column holds value 123\n456\n7890... Am I correct?
No, that's what I was trying to tell you. OGC defined the
Label element so that every "space" element (whitespace, newline,
tab) must be collapsed into a single whitespace element, so
no matter how you struggle a parser respecting the rules will
turn your \n into a whitespace unless you use CDATA and
we have Gabriel patch in (which we don't, right now).
Having newlines _inside_ your data should work instead.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Ok, ok..sorry my stupidity, Andrea! i understand now.
The db record used for testing had a column with the string
PDO37\nPDO38(1:32)\nPDO39\nPDO40.
I updated the record replacing \n with chr(10) and I get this output
http://www.nabble.com/file/p21418554/wms_5.png wms_5.png
i updated again replacing chr(10) with chr(10) || chr(13) and i get the
following output
http://www.nabble.com/file/p21418554/wms_6.png wms_6.png
the sld: http://www.nabble.com/file/p21418554/sld_caption.sld
sld_caption.sld
I'm using the new labeller, without this the label is render like
PDO37PDO38(1:32)PDO39PDO40.
Looking at the both output images seems like the labeller it's adding a
newline for each character.. a bug maybe?
thanks,
Pedro Mendes
Andrea Aime-4 wrote:
Pedro Mendes ha scritto:
Andrea thanks for fast reply. Here it is the sld
http://www.nabble.com/file/p21416162/sld_caption.sld sld_caption.sld
The data is irrelevant because i'm testing putting a string like
'123\n456\n7890' directly in the sld element Label..I think it should be
the
same having
<Label>
<ogc:Literal>123\n456\n7890</ogc:Literal>
<Label>
and
<Label>
<ogc:PropertyName>CAPTION</ogc:PropertyName>
<Label>
where CAPTION column holds value 123\n456\n7890... Am I correct?
No, that's what I was trying to tell you. OGC defined the
Label element so that every "space" element (whitespace, newline,
tab) must be collapsed into a single whitespace element, so
no matter how you struggle a parser respecting the rules will
turn your \n into a whitespace unless you use CDATA and
we have Gabriel patch in (which we don't, right now).
Having newlines _inside_ your data should work instead.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
View this message in context: http://www.nabble.com/Automatic-Label-Wrapping-(Throw-GeoServer-a-curve)-tp21376062p21418554.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
Pedro Mendes wrote:
Looking at the both output images seems like the labeller it's adding a
newline for each character.. a bug maybe?
Should a jira bug be issued on this one?
Pedro Mendes
--
View this message in context: http://www.nabble.com/Automatic-Label-Wrapping-(Throw-GeoServer-a-curve)-tp21376062p21442317.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
Should a jira bug be issued on this one?
Cumps,
Pedro Mendes
Pedro Mendes wrote:
Ok, ok..sorry my stupidity, Andrea! i understand now.
The db record used for testing had a column with the string
PDO37\nPDO38(1:32)\nPDO39\nPDO40.
I updated the record replacing \n with chr(10) and I get this output
http://www.nabble.com/file/p21418554/wms_5.png wms_5.png
i updated again replacing chr(10) with chr(10) || chr(13) and i get the
following output
http://www.nabble.com/file/p21418554/wms_6.png wms_6.png
the sld: http://www.nabble.com/file/p21418554/sld_caption.sld
sld_caption.sld
I'm using the new labeller, without this the label is render like
PDO37PDO38(1:32)PDO39PDO40.
Looking at the both output images seems like the labeller it's adding a
newline for each character.. a bug maybe?
thanks,
Pedro Mendes
Andrea Aime-4 wrote:
Pedro Mendes ha scritto:
Andrea thanks for fast reply. Here it is the sld
http://www.nabble.com/file/p21416162/sld_caption.sld sld_caption.sld
The data is irrelevant because i'm testing putting a string like
'123\n456\n7890' directly in the sld element Label..I think it should be
the
same having
<Label>
<ogc:Literal>123\n456\n7890</ogc:Literal>
<Label>
and
<Label>
<ogc:PropertyName>CAPTION</ogc:PropertyName>
<Label>
where CAPTION column holds value 123\n456\n7890... Am I correct?
No, that's what I was trying to tell you. OGC defined the
Label element so that every "space" element (whitespace, newline,
tab) must be collapsed into a single whitespace element, so
no matter how you struggle a parser respecting the rules will
turn your \n into a whitespace unless you use CDATA and
we have Gabriel patch in (which we don't, right now).
Having newlines _inside_ your data should work instead.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
View this message in context: http://www.nabble.com/Automatic-Label-Wrapping-(Throw-GeoServer-a-curve)-tp21376062p21442333.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
Should be issued a jira bug on this one?
cumps,
pedro mendes
--
View this message in context: http://www.nabble.com/Automatic-Label-Wrapping-(Throw-GeoServer-a-curve)-tp21376062p21442387.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
Pedro Mendes ha scritto:
Pedro Mendes wrote:
Looking at the both output images seems like the labeller it's adding a
newline for each character.. a bug maybe?
Should a jira bug be issued on this one?
No need to send three mails with the same question 
Before you open a jira issue, I'm wondering if you have specified a too
short label wrap parameter. The java text layouter will cut
a word in between if it's longer than the autoWrap size.
So if you, for example, specified:
<VendorOption name="autoWrap">10</VendorOption>
that's pretty much guaranteed to render on char per line
(as you told it to wrap if the line becomes longer than
10 pixels).
As a rule of thumb the autoWrap parameter should be set so
that the longest word still fits in one line.
I looked into having the java TextLayout class not to cut
words in the middle if the wrapping lenght is too short,
but found no obvious way to do so. If anybody has suggestions
in this respect, I'm all ears.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
No need to send three mails with the same question
Sorry..I was replying from the nabble interface and got some problems
Before you open a jira issue, I'm wondering if you have specified a too
short label wrap parameter. The java text layouter will cut
a word in between if it's longer than the autoWrap size.
So if you, for example, specified:
<VendorOption name="autoWrap">10</VendorOption>
that's pretty much guaranteed to render on char per line
(as you told it to wrap if the line becomes longer than
10 pixels).
No, I wasn't specifying a autoWrap value, so it should follow the newlines
inside my data.
As a rule of thumb the autoWrap parameter should be set so
that the longest word still fits in one line.
I looked into having the java TextLayout class not to cut
words in the middle if the wrapping lenght is too short,
but found no obvious way to do so. If anybody has suggestions
in this respect, I'm all ears.
I think if although has newlines and autoWrap is set, autoWrap should be
mandatory.
Otherwise the newlines are respected.
cumps,
Pedro Mendes
Pedro Mendes ha scritto:
No need to send three mails with the same question
Sorry..I was replying from the nabble interface and got some problems
Before you open a jira issue, I'm wondering if you have specified a too
short label wrap parameter. The java text layouter will cut
a word in between if it's longer than the autoWrap size.
So if you, for example, specified:
<VendorOption name="autoWrap">10</VendorOption>
that's pretty much guaranteed to render on char per line
(as you told it to wrap if the line becomes longer than
10 pixels).
No, I wasn't specifying a autoWrap value, so it should follow the newlines
inside my data.
Indeed it should. Do you have some test data and a style for me
so that I can reproduce the issue? A shapefile or a postgis dump
will do fine.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
> No, I wasn't specifying a autoWrap value, so it should follow the
newlines
> inside my data.
Just found out if no autowrap defined it's the same of autowrap=0 pixels.
That's why there was a character per newline.
I tested with autowrap=150 and now newlines from data are being correctly
consider but the label doesn't appear centred with the point coordinates.
Seems like the "box" embracing the label has 100 pixels width and words are
left justify.
If the autowrap pixels are less than the longest word pixels it's cut off
right(as it should) into a newline, the newlines from data are respected but
the label still keeps off his correct position..
Indeed it should. Do you have some test data and a style for me
so that I can reproduce the issue? A shapefile or a postgis dump
will do fine.
I'll sent u some data.
Cumps,
Pedro Mendes
Another finding: if the data has several strings alternate with newlines and
if they aren't pick up by labeller in shortest to longest word order, the
label come up uncentred with the point. Otherwise it come up right.
Cumps,
Pedro Mendes
Andrea Aime-4 wrote:
Pedro Mendes ha scritto:
No need to send three mails with the same question
Sorry..I was replying from the nabble interface and got some problems
Before you open a jira issue, I'm wondering if you have specified a too
short label wrap parameter. The java text layouter will cut
a word in between if it's longer than the autoWrap size.
So if you, for example, specified:
<VendorOption name="autoWrap">10</VendorOption>
that's pretty much guaranteed to render on char per line
(as you told it to wrap if the line becomes longer than
10 pixels).
No, I wasn't specifying a autoWrap value, so it should follow the
newlines
inside my data.
Indeed it should. Do you have some test data and a style for me
so that I can reproduce the issue? A shapefile or a postgis dump
will do fine.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
View this message in context: http://www.nabble.com/Automatic-Label-Wrapping-(Throw-GeoServer-a-curve)-tp21376062p21455592.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
