Hi, I've been looking at 1.6.5 issues to solve yesterday and found GEOS-1661 and GEOS-1620 and recall a thought that rounded my mind when this was discussed.
The thing is, it _is_ by (xml) spec that spaces in a cssparameter element are trimmed and also newlines, BUT what we were missing is that there IS a standards compliant way to include whatever you want verbatim: a CDATA section! So I just modified the snippet in GEOS-1661 to use a CDATA secion with a new line and added the CDATA parsing to SLDParser. The result is that the expression goes down the pipe perfectly until the label needs to actually be rendered, and then its rendered as a single line even if the expression contained the newline character. That is due to the default implementation of GlyphVector knowing how to draw text in a single line and a single font. The way around is to use a java.awt.font.TextLayout instead. But hey, the good news are we figured out how to include whatever you want in the label, CDATA, and know how to fix the rendering... Gabriel On Tuesday 29 July 2008 04:16:13 am Andrea Aime wrote: > Emily Gouge ha scritto: > > I'm following up from the irc chat earlier - to try determine what is the > > "correct" behavior for the SLDParser with regards to preserving > > whitespace in mixed content elements. My understanding is that mixed > > type elements are supposed to collapse all white-space and convert them > > to a single space. > > > > So this would imply that that Label element associated with Text > > Symbolizers should collapse all white-space. I'm currently looking at > > the SLDParser in Geotools and it has a comment that states "the label > > parser should preserve whitespaces". > > Here there is a tension between the standard behaviour, and a useful > one. The schema mandated behaviour is, as you say, to collapse > whitespace. The useful behaviour would be to keep them as is, allowing > people to embed newlines and thus labels. > > > Before I try to wrongly update something can somebody confirm that > > whitespaces should be collapsed and not preserved? If so, I'll create a > > test case and try to make it work. > > My take on this is that yes, we should collapse and be standard compliant. > > We also probably want to create a couple new filter functions, newline() > and space(numSpaces) that allow people to explicitly embed spaces in a > label. This one is catchy thought, since that is but a first step, the > second one would be to make the renderer honour newlines: the java2d > text drawing commands do not do text layout, and handling newlines falls > into the layout issues. That would require some major changes in the > way we do draw labels, it's not going to happen overnight. > > Cheers > Andrea > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge Build the coolest Linux based applications with Moblin SDK & win > great prizes Grand prize is a trip for two to an Open Source event anywhere > in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > !DSPAM:4045,488ec3da87605210051143! ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
