catching up...
On Thursday 01 March 2007 21:02, Chris Holmes wrote:
Yeah, we use anti-aliasing extensively, it tends to make things look a
lot better.
SVG, however, is one that probably benefits very little from
anti-aliasing, since it's a vector format (though I could be wrong).
the antialiasing rendering hint has no effect for the batik Graphics2D
implementation, it just don't apply. But almost everytime you see an svg
graphic you're seeing it antialiased though, since thats just a viewer option
and most viewers use antialiasing by default to present svg.
I think the batik rendering route is less than ideal, since it turns it
in to a raster and then constructs a vector out of that, which is silly
because we're going from vectors in our data.
uglier than that, it turns it into a DOM and then serializes the dom.
The solution would be to make a special SVG output format that doesn't
use batik.
Or to find out an "extension point" on the batik that writes the content right
away to an outputstream instead of building a DOM, or to just steal the batik
code that generates the svg stying from the Graphic2D methods, make a prescan
based on the SLD and build a map of SLD stylers/SVG style, write them at the
svg header, and then use the streaming encoder and set a class property for
each geometry which xlinks to the correct style...
sounds easy but I got lost more than once trying to do that. Never had enough
time to try seriously though, and you know I'm slow 
Cheers,
Gabriel
Chris
Jiri Kozel wrote:
> I'm not a graphic specialist, but I think it has something to do with
> anti-aliasing. SVG renderering could be good example. Look at the
> picture, it shows black line with width 1.0, 1.25, 1.5, 1.75 and 2.0.
> http://www.nabble.com/file/6868/1-2.bmp
>
> The second thing is, that Geoserver can already draw lines of fractional
> width, but only from 1.5 to greater values (I've tried it). Furthermore,
> output GeoServer's PNGs look like antialiased, so I guess it already do
> some kind of anti-aliasing.
>
> Jiri
>
> Ian Turton wrote:
>> On 3/1/07, Jiri Kozel <jirikozel@anonymised.com> wrote:
>>> Ian,
>>> You're right, I haven't read the last sentence about fractional numbers
>>> and
>>> system dependance. So sorry for my bad opinion.
>>>
>>> Value 0 returns the same width as anyother value lesser than 1.5, but
>>> as you
>>> say: "drawing something is the 'right thing to do'"
>>>
>>> Anyway, it would be nice if GeoServer could draw lines with fractional
>>> value
>>> width. There is a quite great difference between visual appearance of
>>> 1.49
>>> and 1.5 width (mainly in png format).
>>
>> The problem is what does 1.5 pixels mean. Even when we move to the new
>> symbology encoding spec
>> (http://www.opengeospatial.org/standards/symbol) which allows you to
>> specify a width of 5 metres for your line, its still going to be an
>> integer number of pixels wide when its drawn.
>>
>> Ian
>> --
>>
>> Ian Turton
>> http://www.geotools.org
>> http://pennspace.blogspot.com/
>>
>> ------------------------------------------------------------------------
>>- Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share
>> your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
>>V _______________________________________________
>> Geoserver-users mailing list
>> Geoserver-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
