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.
From: John C. Turnbull [mailto:[email protected]] Sent: Monday, 19 January 2009 16:23 To: [email protected] Subject: RE: Rendering problems with thin borders Hi Thomas, I am finding that for some of the SVGs I am working with it is sufficient to modify the stroke as you suggested but for many of them they are rendering obscure shapes and the stroke painter is not invoked. 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. Thanks, John 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.
