You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Archie Cobbs <ar...@dellroad.org> on 2006/10/20 03:52:49 UTC
Optimizing SVG via XSL
FYI,
If anyone is interested I've posted a couple of SVG "optimizer" XSL
transforms to the wiki. These basically covert <rect>, etc. elements
into <path> elements, and then consolidated consecutive <path>
elements into a single <path> element. For certain machine generated
SVG documents, this saves a lot of overhead in Batik. Let me know if
you find any bugs or have any ideas for improvement.
http://wiki.apache.org/xmlgraphics-batik/OptimizingStylesheets
Cheers,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Optimizing SVG via XSL
Posted by Archie Cobbs <ar...@dellroad.org>.
On 10/26/06, thomas.deweese@kodak.com <th...@kodak.com> wrote:
> > I'm not sure I understand.. could you give a small example?
>
> I thought I had (duh!).
Thanks.. I added this to the wiki page.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Optimizing SVG via XSL
Posted by th...@kodak.com.
Hi Archie,
archie.cobbs@gmail.com wrote on 10/26/2006 09:48:23 AM:
> On 10/26/06, thomas.deweese@kodak.com <th...@kodak.com> wrote:
> > > The logic is simply that two consecutive path elements will be
> > > consolidated if they have the exact same set of attributes,
> > > other than the "d" and "pathLength" attributes.
> >
> > Ohh, this won't even work for normal elements if they have a
> > stroke, unless the element's don't overlap.
> I'm not sure I understand.. could you give a small example?
I thought I had (duh!).
<svg width="400" height="400"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink">
<!-- outline issue -->
<g transform="translate(0, 0)">
<!-- two elements -->
<path fill="#DDD" stroke="#000" d="m0,0 100,0 0,100 -100,0 z"/>
<path fill="#DDD" stroke="#000" d="m50,50 100,0 0,100 -100,0 z"/>
</g>
<g transform="translate(200, 0)">
<!-- one element -->
<path fill="#DDD" stroke="#000"
d="m0,0 100,0 0,100 -100,0 z
m50,50 100,0 0,100 -100,0 z"/>
</g>
<g transform="translate(0, 200)">
<style type="text/css">
path.button { fill: #00F; }
path + path.button { fill: #888; }
</style>
<!-- this will be blue -->
<path class="button" fill="#F00" d="m0,0 100,0 0,100 -100,0 z"/>
<!-- this will be grey -->
<path class="button" fill="#F00" d="m50,50 100,0 0,100 -100,0 z"/>
</g>
</svg>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Optimizing SVG via XSL
Posted by Archie Cobbs <ar...@dellroad.org>.
On 10/26/06, thomas.deweese@kodak.com <th...@kodak.com> wrote:
> > My algorithm may very well be wrong in the general case but works for
> > the documents I've been using. The logic is simply that two
> > consecutive path elements will be consolidated if they have the exact
> > same set of attributes, other than the "d" and "pathLength"
> > attributes.
>
> Ohh, this won't even work for normal elements if they have a
> stroke, unless the element's don't overlap. It will change
> fill1 -> stroke1 -> fill2 -> stroke2 into
> fill1 -> fill2 -> stroke1 -> stroke2. So if any part of 'stroke1'
> should be hidden by 'fill2' it won't be anymore. This might still
> be a useful enhancement but it can easily change rendering...
I'm not sure I understand.. could you give a small example?
> > I had assumed that if two <path>'s had the same attributes
> > then you could consolidate them, but maybe this is not true?
>
> This is not true in the general case. The work is still
> useful but the assumptions the scripts use should be documented
> (as well as at least the above two potential problems).
I'll update the wiki page.
Thanks,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: probleme rasterizing "big" svg ?
Posted by benamou <je...@inria.fr>.
OK thanks Thomas it works.
Do you know if repeated exception like that can corrupt
batik (probably not) or the JRE on a window box ?
I have it running on a delocalized server and it seems
that even small files which were converted OK can
not be treated now.
JD
----- Original Message -----
From: <th...@kodak.com>
To: <ba...@xmlgraphics.apache.org>
Cc: <ba...@xmlgraphics.apache.org>
Sent: Thursday, October 26, 2006 9:05 PM
Subject: Re: probleme rasterizing "big" svg ?
> Hi Jean,
>
> Try giving java some more memory:
>
> % java -Xmx512m -jar batik-rasterizer.jar -onload -m
> application/pdf 99.svg
>
> The default Java partition can only grow to a pitling 64Mb, the above
> bumps it to 512Mb.
>
> benamou jean-david <je...@inria.fr> wrote on 10/26/2006
> 06:35:08 PM:
>
>> C:\batik-1.6>java -jar batik-rasterizer.jar -onload -m application/
>> pdf 99.svg
>> About to transcode 1 SVG file(s)
>>
>> Converting 99.svg to 99.pdf ... Exception in thread "main"
>> java.lang.OutOfMemory
>> Error: Java heap space
>>
>> C:\batik-1.6>
>>
>>
>> 99.svg is 1Mo
>> Does that means that this file is simply to big ?
>>
>> Thanks
>> JD
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: probleme rasterizing "big" svg ?
Posted by th...@kodak.com.
Hi Jean,
Try giving java some more memory:
% java -Xmx512m -jar batik-rasterizer.jar -onload -m
application/pdf 99.svg
The default Java partition can only grow to a pitling 64Mb, the above
bumps it to 512Mb.
benamou jean-david <je...@inria.fr> wrote on 10/26/2006
06:35:08 PM:
> C:\batik-1.6>java -jar batik-rasterizer.jar -onload -m application/
> pdf 99.svg
> About to transcode 1 SVG file(s)
>
> Converting 99.svg to 99.pdf ... Exception in thread "main"
> java.lang.OutOfMemory
> Error: Java heap space
>
> C:\batik-1.6>
>
>
> 99.svg is 1Mo
> Does that means that this file is simply to big ?
>
> Thanks
> JD
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
probleme rasterizing "big" svg ?
Posted by benamou jean-david <je...@inria.fr>.
C:\batik-1.6>java -jar batik-rasterizer.jar -onload -m application/
pdf 99.svg
About to transcode 1 SVG file(s)
Converting 99.svg to 99.pdf ... Exception in thread "main"
java.lang.OutOfMemory
Error: Java heap space
C:\batik-1.6>
99.svg is 1Mo
Does that means that this file is simply to big ?
Thanks
JD
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Fwd: Optimizing SVG via XSL
Posted by Archie Cobbs <ar...@dellroad.org>.
Apologies if this is a duplicate... I sent this out from the wrong
email address so it probably didn't make it to the list...
---------- Forwarded message ----------
From: Archie Cobbs <ar...@gmail.com>
Date: Oct 24, 2006 8:48 AM
Subject: Re: Optimizing SVG via XSL
To: "thomas.deweese@kodak.com" <th...@kodak.com>
Cc: batik-users@xmlgraphics.apache.org
On 10/24/06, thomas.deweese@kodak.com <th...@kodak.com> wrote:
> > then consolidated consecutive <path> elements into a single
> > <path> element.
>
> How do you determine if it's safe to consolidate consecutive
> <path> elements? Since styling is done by CSS this would seem
> essentially impossible in the general case (selectors) so what
> assumptions do you make?
My algorithm may very well be wrong in the general case but works for
the documents I've been using. The logic is simply that two
consecutive path elements will be consolidated if they have the exact
same set of attributes, other than the "d" and "pathLength"
attributes.
I'm not familiar enough with CSS and selectors (what are those? :-) to
know if this logic would break documents using them. I had assumed
that if two <path>'s had the same attributes then you could
consolidate them, but maybe this is not true?
Thanks,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
--
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Optimizing SVG via XSL
Posted by th...@kodak.com.
Hi Archie,
"Archie Cobbs" <ar...@gmail.com> wrote on 10/24/2006 09:48:08 AM:
> On 10/24/06, thomas.deweese@kodak.com <th...@kodak.com> wrote:
> > > then consolidated consecutive <path> elements into a single
> > > <path> element.
> >
> > How do you determine if it's safe to consolidate consecutive
> > <path> elements? Since styling is done by CSS this would seem
> > essentially impossible in the general case (selectors) so what
> > assumptions do you make?
>
> My algorithm may very well be wrong in the general case but works for
> the documents I've been using. The logic is simply that two
> consecutive path elements will be consolidated if they have the exact
> same set of attributes, other than the "d" and "pathLength"
> attributes.
Ohh, this won't even work for normal elements if they have a
stroke, unless the element's don't overlap. It will change
fill1 -> stroke1 -> fill2 -> stroke2 into
fill1 -> fill2 -> stroke1 -> stroke2. So if any part of 'stroke1'
should be hidden by 'fill2' it won't be anymore. This might still
be a useful enhancement but it can easily change rendering...
> I'm not familiar enough with CSS and selectors (what are those? :-) to
> know if this logic would break documents using them.
Selectors allow you to more or less arbitrarily change
the 'style' of an element in the DOM based on many things (see
my example at the end for just one example of this).
> I had assumed that if two <path>'s had the same attributes
> then you could consolidate them, but maybe this is not true?
This is not true in the general case. The work is still
useful but the assumptions the scripts use should be documented
(as well as at least the above two potential problems).
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Optimizing SVG via XSL
Posted by Archie Cobbs <ar...@gmail.com>.
On 10/24/06, thomas.deweese@kodak.com <th...@kodak.com> wrote:
> > then consolidated consecutive <path> elements into a single
> > <path> element.
>
> How do you determine if it's safe to consolidate consecutive
> <path> elements? Since styling is done by CSS this would seem
> essentially impossible in the general case (selectors) so what
> assumptions do you make?
My algorithm may very well be wrong in the general case but works for
the documents I've been using. The logic is simply that two
consecutive path elements will be consolidated if they have the exact
same set of attributes, other than the "d" and "pathLength"
attributes.
I'm not familiar enough with CSS and selectors (what are those? :-) to
know if this logic would break documents using them. I had assumed
that if two <path>'s had the same attributes then you could
consolidate them, but maybe this is not true?
Thanks,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Optimizing SVG via XSL
Posted by th...@kodak.com.
Hi Archie,
archie.cobbs@gmail.com wrote on 10/19/2006 09:52:49 PM:
> If anyone is interested I've posted a couple of SVG "optimizer" XSL
> transforms to the wiki.
Thanks for the contribution.
> then consolidated consecutive <path> elements into a single
> <path> element.
How do you determine if it's safe to consolidate consecutive
<path> elements? Since styling is done by CSS this would seem
essentially impossible in the general case (selectors) so what
assumptions do you make?
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org