[PATCH] More control over RasterizerTask output files

[Martin von Gagern <Ma...@gmx.net>]

Hi!

I plan to use ant & batik to build a project web page. For this I had a
tree of SVG sources and an ant task to rasterize them. I was surprised
to find that the tree structure was lost and instead all result images
put directly into the target directory. Most other ant tasks keep
directory structures, relative to the base directory of a fileset.

I decided to try to address this issue. In order to allow for even more
flexibility, I plugged in a mapper as well. Now people can use mappers
to control what source files will get transformed to what result files.

The current state of the patch reflects behaviour as I would wish it to
be. It is, however, an incompatible modification, as other builds might
rely on the flattening. If you are concerned about backwards
compatibility, I can think of two possibilities:

1. Use flattening whenever no mapper is present.
2. Provide a flatten attribute, defaulting to yes.

I think I would prefer the latter, but would like your opinion whether
we should aim for backwards compatibility at all in the first place.
And of course I'd be grateful for any kind of useful comment you have
about my modifications.

The patch also modifies the build.xml file in order to help people to
avoid build.sh resp. build.bat. There are classpath elements pointing at
batik as well as inclusions for jar files from a lib directory where
people could simply drop dependencies.

Greetings,
 Martin von Gagern

Re: [PATCH] More control over RasterizerTask output files

[Helder Magalhães <he...@gmail.com>]

Hi Martin,

> I decided to try to address this issue. In order to allow for even more
> flexibility, I plugged in a mapper as well. Now people can use mappers
> to control what source files will get transformed to what result files.

Thanks for sharing your solution. :-)


> The current state of the patch reflects behaviour as I would wish it to
> be. It is, however, an incompatible modification, as other builds might
> rely on the flattening. If you are concerned about backwards
> compatibility, I can think of two possibilities:
>
> 1. Use flattening whenever no mapper is present.
> 2. Provide a flatten attribute, defaulting to yes.
>
> I think I would prefer the latter, but would like your opinion whether
> we should aim for backwards compatibility at all in the first place.
> And of course I'd be grateful for any kind of useful comment you have
> about my modifications.

For backwards compatibility's sake, I'd suggest leaving the default to
the current behavior.


As this hasn't received any feedback within about a month, I've
created bug 46926 [1] to deal with this.


> Greetings,
>  Martin von Gagern

Regards,
 Helder Magalhães


[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=46926

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org