Hi John, "John C. Turnbull" <[email protected]> wrote on 01/19/2009 05:37:08 AM:
> I think I have discovered something... the vanishing lines and > borders and shape edges seems to have nothing to do with the stroke > being used but everything to do with what looks like a bug in Java2D > clipping with transforms. I printed out the stroke and shape > details being painted in StrokeShapePainter when the SVG consisted > of a simple rectangle and found that the dimensions and stroke of > the rectangle never change for any zoom level and all that changes > is the affine transform in place. I further found that if I changed > the clip to be a rectangle one pixel wider and taller than the one > being rendered then there are no problems with disappearing lines. > > It seems that at certain zoom levels (i.e. certain affine > transforms), using the shape being rendered as the clip region > causes some parts of the shape to disappear. It doesn’t seem to be > related to the actual zoom level in place as parts can disappear and > then reappear as you zoom in all the way or zoom out all the way. I > was able to reproduce this behaviour using simple Java2D in another > test program. > > Comments? If you agree it’s a Java2D issue then I will post on the > appropriate forum and try to get an answer. It is true that the Java2D anti-aliaser occasionally doesn't match up exactly with the hard edge clip. However except for content that makes use of clip paths internally this should only effect the edge of the drawing. You could also try turning on anti-aliased clipping by making sure 'shape-rendering' is set to 'geometricPrecision' on the 'clipPath' elements (this can be done with a CSS style sheet). Also I don't know if the various rendering hints (especially 'stroke pure') also effect the clip path when used as a hard-edged clip. Finally apparently the rendering has changed a bit in the very latest JDK 1.6 release. > From: John C. Turnbull [mailto:[email protected]] > > The more I think about this the more I feel this should actually be > regarded as a bug in Batik as all the other viewers I have tried do > not ever fail to render a line or a border when zoomed out or > resized quite small. It seems to be a problem unique to Batik. Feel free to mark it as a bug, but since we just use the Java2D library we won't be fixed unless it is fixed. > From: John C. Turnbull [mailto:[email protected]] > Sent: Monday, 19 January 2009 16:23 > I take it that when you say “writing a new rasterizer” we are not > talking about a trivial task? Well, it would be so nice if I could > somehow do that as I really want to be able to zoom out on these > SVGs without their borders disappearing at smaller scales. Can it > be done? I am willing to put in the effort if it’s really feasible. Writing a new rasterizer is extremely challenging. The rasterizer is what goes from a 'Path' to a set of per-pixel coverages, which can be used to fill shapes. Getting the results right and doing it quickly is very difficult, plus you would be operating at a disadvantage since the Java2D libraries are native code vs Java code. > From: [email protected] [mailto:[email protected]] > Sent: Sunday, 4 January 2009 01:29 > To: [email protected] > Cc: [email protected] > Subject: Re: Rendering problems with thin borders > > > Hi John, > > "John C. Turnbull" <[email protected]> wrote on 12/31/2008 10:33:46 PM: > > > I have a number of SVGs which feature graphics with thin borders. > > The problem is that with Batik when it renders those SVGs at smaller > > sizes, it tends to not display all or parts of the border at all. > > > > How difficult would it be to modify Batik so that it never fails to > > render something because it becomes “too thin” but rather renders it > > with a higher alpha value instead to give the illusion of thinness > > at smaller scales? > > As long as we are talking about true SVG strokes it might be > possible by adjusting batik.gvt.StrokingShapePainter so that it > checks the screen stroke width in it's paint method and then > replace the 'real' stroke with a wider stroke to maintain some > minimal stroke width (say .5 screen pixel or something). > > If the SVG content actually draws the thin lines as shapes > then detecting/fixing these would effectively require writing > a new rasterizer.
