Gaps / Aliasing in SVG rendering

[apm-2]

Hello!  I've tried searching the mailing list archives and found some  
relevant information but did not find a satisfactory answer.  However,  
if I've missed something please do berate me accordingly ;)

I have an SVG file:
http://apmatthe.ws/svg/132g1.svg

When I load it into Illustrator, The Gimp, Firefox or Safari it looks  
like this:
http://apmatthe.ws/svg/illus_132g1.png

When I load it into Squiggle or batik-rasterizer it looks like this:
http://apmatthe.ws/svg/batik_132g1.png

I've tried using geometricPrecision shape rendering, no dice.  
crispEdges gets better results but a lack of anti-aliasing is not  
ideal.  I've tried using the most recent nightly build, no dice.  I'm  
on OSX but I tried it on my Windows system with the same results.

I have about a thousand of these SVG files; it would be impractical to  
manually edit those which are afflicted by this if that's the only  
solution, therefore *any* help would be greatly appreciated.

Many thanks!
- ap

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@...
For additional commands, e-mail: batik-users-help@...

[Helder Magalhães]

> I have an SVG file:
> http://apmatthe.ws/svg/132g1.svg

> therefore *any* help would be greatly appreciated.

The file itself seems a bit broken. The shapes within the file don't
make much sense and there is a number of vertical lines which seem to
be causing this symptom. Try setting 'stroke="blue"' in the "main"
group ("g" element), which will highlight the contour of shapes, to
see what's going on...

There have been a number of reports that the SVG export plug-in of
Adobe Illustrator has a few issues. Nevertheless, by looking at the
file, it seems as if someone had tried to vectorize a preexistent
file, due to the large number of weird curves (try zooming in a couple
of times). Is this the case? Are the shapes within the original file
correct?

I'm not arguing about the geometric precision of Batik - I believe
this should be further investigated to check for a lack of precision
(in Batik or Illustrator?), possibly a content issue, etc...

Finally, I've confirmed that using "crispEdges" seems to workaround
the issue. I'm using Java 6 update 7 on Windows XP SP3 and Squiggle of
both Batik 1.7 release and of the latest nightly build [1].

Regards,

 Helder Magalhães

[1] http://arc.mcc.id.au/batik-nightly/

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@...
For additional commands, e-mail: batik-users-help@...

[apm-2]

Thanks for your response Helder.  Yes, the shapes are correct.

It is entirely possible that the heart of the issue lies in the SVGs I  
am attempting to render.  However when I load this same SVG back into  
Illustrator or The Gimp or any web browser it renders without the  
vertical gaps.  Only with Batik do I get these anomalies.

This leads me to believe there is something unique in Batik's anti-
aliasing technique that, in this case, does not work to my favor.

The only quick fix I can think of is to rasterize the SVG (with  
crispEdges) at a very high resolution and then resize it to the  
resolution I need using bicubic resampling from an image library to  
get a pseudo-antialiased rendering.


On Dec 20, 2008, at 7:37 AM, Helder Magalhães wrote:

>> I have an SVG file:
>> http://apmatthe.ws/svg/132g1.svg
>
>> therefore *any* help would be greatly appreciated.
>
> The file itself seems a bit broken. The shapes within the file don't
> make much sense and there is a number of vertical lines which seem to
> be causing this symptom. Try setting 'stroke="blue"' in the "main"
> group ("g" element), which will highlight the contour of shapes, to
> see what's going on...
>
> There have been a number of reports that the SVG export plug-in of
> Adobe Illustrator has a few issues. Nevertheless, by looking at the
> file, it seems as if someone had tried to vectorize a preexistent
> file, due to the large number of weird curves (try zooming in a couple
> of times). Is this the case? Are the shapes within the original file
> correct?
>
> I'm not arguing about the geometric precision of Batik - I believe
> this should be further investigated to check for a lack of precision
> (in Batik or Illustrator?), possibly a content issue, etc...
>
> Finally, I've confirmed that using "crispEdges" seems to workaround
> the issue. I'm using Java 6 update 7 on Windows XP SP3 and Squiggle of
> both Batik 1.7 release and of the latest nightly build [1].
>
> Regards,
>
> Helder Magalhães
>
> [1] http://arc.mcc.id.au/batik-nightly/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@...
> For additional commands, e-mail: batik-users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@...
For additional commands, e-mail: batik-users-help@...

[thomas.deweese]

Hi apmatthews,

apm <apmatthews@...> wrote on 12/21/2008 08:53:36 PM:

> It is entirely possible that the heart of the issue lies in the SVGs I  
> am attempting to render.  However when I load this same SVG back into  
> Illustrator or The Gimp or any web browser it renders without the  
> vertical gaps.  Only with Batik do I get these anomalies.
>
> This leads me to believe there is something unique in Batik's anti-
> aliasing technique that, in this case, does not work to my favor.

   Batik simply uses the Java2D rendering engine, so there isn't a
lot we can do about this problem.  I've checked the various rendering
hints that we can set and they don't help.  I'll just mention that
as the SVG rendering requirements stand Batik's rendering is likely
fully conformant (rendering must be within 1px of the mathematically
correct value).

   The one thing that did help was building an 'Area' object for
the shape.  I don't want to put this in the main-line code as I
suspect it has very large performance implications (especially for
dynamic content) but it might be useful for you.  (see end of message).

> The only quick fix I can think of is to rasterize the SVG (with  
> crispEdges) at a very high resolution and then resize it to the  
> resolution I need using bicubic resampling from an image library to  
> get a pseudo-antialiased rendering.

   There is nothing pseudo-antialiasing about this, in fact the
anti-aliasing renderers do is an approximation of this approach.
This will generally give you better results (at the cost of much greater
CPU/Memory usage).

Index: sources/org/apache/batik/gvt/ShapeNode.java
===================================================================
--- sources/org/apache/batik/gvt/ShapeNode.java (revision 718310)
+++ sources/org/apache/batik/gvt/ShapeNode.java (working copy)
@@ -85,7 +85,8 @@
     public void setShape(Shape newShape) {
         fireGraphicsNodeChangeStarted();
         invalidateGeometryCache();
-        this.shape = newShape;
+        this.shape = new java.awt.geom.Area(newShape);
         if(this.shapePainter != null){
             if (newShape != null) {
                 this.shapePainter.setShape(newShape);

> On Dec 20, 2008, at 7:37 AM, Helder Magalhães wrote:
>
> >> I have an SVG file:
> >> http://apmatthe.ws/svg/132g1.svg
> >
> >> therefore *any* help would be greatly appreciated.
> >
> > The file itself seems a bit broken. The shapes within the file don't
> > make much sense and there is a number of vertical lines which seem to
> > be causing this symptom. Try setting 'stroke="blue"' in the "main"
> > group ("g" element), which will highlight the contour of shapes, to
> > see what's going on...
> >
> > There have been a number of reports that the SVG export plug-in of
> > Adobe Illustrator has a few issues. Nevertheless, by looking at the
> > file, it seems as if someone had tried to vectorize a preexistent
> > file, due to the large number of weird curves (try zooming in a couple
> > of times). Is this the case? Are the shapes within the original file
> > correct?
> >
> > I'm not arguing about the geometric precision of Batik - I believe
> > this should be further investigated to check for a lack of precision
> > (in Batik or Illustrator?), possibly a content issue, etc...
> >
> > Finally, I've confirmed that using "crispEdges" seems to workaround
> > the issue. I'm using Java 6 update 7 on Windows XP SP3 and Squiggle of
> > both Batik 1.7 release and of the latest nightly build [1].
> >
> > Regards,
> >
> > Helder Magalhães
> >
> > [1] http://arc.mcc.id.au/batik-nightly/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@...
> > For additional commands, e-mail: batik-users-help@...
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@...
> For additional commands, e-mail: batik-users-help@...
>

[apm-2]

Thomas, your patch works perfect.  I will run some benchmarks to test performance for our needs but regardless I very much appreciate you looking into this and clarifying the issue.

Thanks for your help,

- ap

On Dec 22, 2008, at 3:43 AM, thomas.deweese@... wrote:

Hi apmatthews,

apm <apmatthews@...> wrote on 12/21/2008 08:53:36 PM:

> It is entirely possible that the heart of the issue lies in the SVGs I  
> am attempting to render.  However when I load this same SVG back into  
> Illustrator or The Gimp or any web browser it renders without the  
> vertical gaps.  Only with Batik do I get these anomalies.
>
> This leads me to believe there is something unique in Batik's anti-
> aliasing technique that, in this case, does not work to my favor.

   Batik simply uses the Java2D rendering engine, so there isn't a
lot we can do about this problem.  I've checked the various rendering
hints that we can set and they don't help.  I'll just mention that
as the SVG rendering requirements stand Batik's rendering is likely
fully conformant (rendering must be within 1px of the mathematically
correct value).

   The one thing that did help was building an 'Area' object for
the shape.  I don't want to put this in the main-line code as I
suspect it has very large performance implications (especially for
dynamic content) but it might be useful for you.  (see end of message).

> The only quick fix I can think of is to rasterize the SVG (with  
> crispEdges) at a very high resolution and then resize it to the  
> resolution I need using bicubic resampling from an image library to  
> get a pseudo-antialiased rendering.

   There is nothing pseudo-antialiasing about this, in fact the
anti-aliasing renderers do is an approximation of this approach.
This will generally give you better results (at the cost of much greater
CPU/Memory usage).

Index: sources/org/apache/batik/gvt/ShapeNode.java
===================================================================
--- sources/org/apache/batik/gvt/ShapeNode.java (revision 718310)
+++ sources/org/apache/batik/gvt/ShapeNode.java (working copy)
@@ -85,7 +85,8 @@
     public void setShape(Shape newShape) {
         fireGraphicsNodeChangeStarted();
         invalidateGeometryCache();
-        this.shape = newShape;
+        this.shape = new java.awt.geom.Area(newShape);
         if(this.shapePainter != null){
             if (newShape != null) {
                 this.shapePainter.setShape(newShape);

> On Dec 20, 2008, at 7:37 AM, Helder Magalhães wrote:
>
> >> I have an SVG file:
> >> http://apmatthe.ws/svg/132g1.svg
> >
> >> therefore *any* help would be greatly appreciated.
> >
> > The file itself seems a bit broken. The shapes within the file don't
> > make much sense and there is a number of vertical lines which seem to
> > be causing this symptom. Try setting 'stroke="blue"' in the "main"
> > group ("g" element), which will highlight the contour of shapes, to
> > see what's going on...
> >
> > There have been a number of reports that the SVG export plug-in of
> > Adobe Illustrator has a few issues. Nevertheless, by looking at the
> > file, it seems as if someone had tried to vectorize a preexistent
> > file, due to the large number of weird curves (try zooming in a couple
> > of times). Is this the case? Are the shapes within the original file
> > correct?
> >
> > I'm not arguing about the geometric precision of Batik - I believe
> > this should be further investigated to check for a lack of precision
> > (in Batik or Illustrator?), possibly a content issue, etc...
> >
> > Finally, I've confirmed that using "crispEdges" seems to workaround
> > the issue. I'm using Java 6 update 7 on Windows XP SP3 and Squiggle of
> > both Batik 1.7 release and of the latest nightly build [1].
> >
> > Regards,
> >
> > Helder Magalhães
> >
> > [1] http://arc.mcc.id.au/batik-nightly/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@...
> > For additional commands, e-mail: batik-users-help@...
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@...
> For additional commands, e-mail: batik-users-help@...
>

[Helder Magalhães]

> Thomas, your patch works perfect.  I will run some benchmarks to test
> performance for our needs but regardless I very much appreciate you looking
> into this and clarifying the issue.

Great to know you are on your way. :-)

Would it be possible to share the benchmarking results to the list
afterward so this particular change could possibly be committed to the
trunk? (If, as Thomas hinted, it wouldn't hurt performance much, of
course.)

I'm don't know if doing some memory measurements would also be a good
idea, for comparing the difference and watch for a possible regression
in terms of memory usage... ;-)

Regards,

 Helder

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@...
For additional commands, e-mail: batik-users-help@...

[thomas.deweese]

Hi Helder,

"Helder Magalhães" <helder.magalhaes@...> wrote on 12/23/2008 07:15:39 AM:

> > Thomas, your patch works perfect.  I will run some benchmarks to test
> > performance for our needs but regardless I very much appreciate you looking
> > into this and clarifying the issue.
>
> Would it be possible to share the benchmarking results to the list
> afterward so this particular change could possibly be committed to the
> trunk?

   I second this request.

> (If, as Thomas hinted, it wouldn't hurt performance much, of course.)

   Actually I hinted it would hurt performance, I suspect a fair
amount.  Of course in his case he doesn't have much choice.

> I'm don't know if doing some memory measurements would also be a good
> idea, for comparing the difference and watch for a possible regression
> in terms of memory usage... ;-)

   Yes, it's possible that for lots of complex geometry the Area class
will use significantly more memory.

[apm-2]

> Would it be possible to share the benchmarking results to the list
> afterward so this particular change could possibly be committed to the
> trunk?

I compared the code converting around 65 SVG files in the 4kb-500kb  
size range to PNGs.  It took ~20.3 seconds using the Dec 7th build.  
With the patch it took ~28.5 seconds.

> I'm don't know if doing some memory measurements would also be a good
> idea, for comparing the difference and watch for a possible regression
> in terms of memory usage... ;-)

This was the surprise (for me) with the patch, when I put in an SVG  
greater than 500kb it would fail with an out of memory error.  I can  
do +900kb SVGs without the patch though it does take its time.

I wager that's probably more or less what Thomas expected.  Doesn't  
quite solve my problem since I do have some large SVG files, but I do  
at least have a better idea of what sort of compromises I may have to  
make.

cheers.

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@...
For additional commands, e-mail: batik-users-help@...

[Helder Magalhães]

> I compared the code converting around 65 SVG files in the 4kb-500kb size
> range to PNGs.  It took ~20.3 seconds using the Dec 7th build.  With the
> patch it took ~28.5 seconds.

Yeah, it's probably ever a much bigger hit for more common usage
patterns such as viewing files and navigating them: for rasterizing
files, I'm guessing that a single rendering of the graphic is
performed so these measements can be somehow obfuscating... :-/

> This was the surprise (for me) with the patch, when I put in an SVG greater
> than 500kb it would fail with an out of memory error.  I can do +900kb SVGs
> without the patch though it does take its time.
>
> I wager that's probably more or less what Thomas expected.  Doesn't quite
> solve my problem since I do have some large SVG files, but I do at least
> have a better idea of what sort of compromises I may have to make.

Well, for working around the specific problem with large files, you
may attempt to increase the memory available for the Java runtime
environment. Searching the mailing list [1] for "Xmx" for a bunch of
threads on how to do it. ;-)

Hope this helps,

 Helder

[1] http://www.nabble.com/Batik-f308.html

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@...
For additional commands, e-mail: batik-users-help@...

[thomas.deweese]

Hi APMatthews,

apm <apmatthews@...> wrote on 12/25/2008 08:32:12 PM:

> > Would it be possible to share the benchmarking results to the list
> > afterward so this particular change could possibly be committed to the
> > trunk?
>
> I compared the code converting around 65 SVG files in the 4kb-500kb  
> size range to PNGs.  It took ~20.3 seconds using the Dec 7th build.  
> With the patch it took ~28.5 seconds.

   So roughly a 40% increase.  The effective increase would probably
be greater for Dynamic content as it doesn't have the parsing and basic
tree construction overhead.

> > I'm don't know if doing some memory measurements would also be a good
> > idea, for comparing the difference and watch for a possible regression
> > in terms of memory usage... ;-)
>
> This was the surprise (for me) with the patch, when I put in an SVG  
> greater than 500kb it would fail with an out of memory error.  I can  
> do +900kb SVGs without the patch though it does take its time.

   So Helter's suggestion of Xmx will probably help/solve the problem
(the normal default memory partition is tiny ~64MB).  Also you could
probably mostly eliminate the extra memory overhead by constructing
a GeneralPath from the Area Object:

        new GeneralPath(new Area(shape));

> I wager that's probably more or less what Thomas expected.  Doesn't  
> quite solve my problem since I do have some large SVG files, but I do  
> at least have a better idea of what sort of compromises I may have to  
> make.

   I think Xmx and/or the above addition will get you going again...

[apm-2]

On Dec 26, 2008, at 10:56 AM, Helder Magalhães wrote:

> Well, for working around the specific problem with large files, you
> may attempt to increase the memory available for the Java runtime
> environment. Searching the mailing list [1] for "Xmx" for a bunch of
> threads on how to do it. ;-)

Ah, thanks for that.  Not coming from the strongest of Java  
backgrounds here, I'm afraid. :)

cheers,
- ap
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@...
For additional commands, e-mail: batik-users-help@...