Hello, Thanks for your answer !! Be assured that I don't considered the lack of answer until now as disinterest !! I re-posted it on the main mailing list because I thought that it was easy to let bug / RFE reports pass without noticing, and also because of its dependency on another Apache project, and the fact that it involved a "big" donation of code, it was for me more complex than regular patches sent for others bugs / RFE.
As for the use case, the idea of thyis RFE it began as a kind of a "workaround" on the "need" of SVG => WMF / EMF transcoding (that's another RFE which number I don't remember now), but I confess that I don't know if SVG => WMF / EMF is mainstream or not ;) I think that what you proposed is the best for the moment. I will start an OpenSource project under an Apache license for this, and link to it in the bugzilla report. Hervé Girod >Hi Hervé, >I don't have an immediate use case for this myself, but I generally find >it interesting functionality. You should probably not take no answer >until now as disinterest. I assume we're just seeing the somewhat >inevitable properties of a mature project which works fine for >99% of >the users and developers. One could say that this functionality you're >proposing is not exactly main-stream. ;-) >My 0.05 CHF on this: If you don't get any Batik developers jumping on >the new functionality and wanting to see patches (because they may not >have enough time at the moment), I think it is a good idea to publish >your transcoder on some light-weight OSS infrastructure (like Google >Code) and announce it here on the lists (demanding it be linked to from >the Batik website). At the moment, it would also allow you to avoid all >the procedural hoops involved with a larger donation of code to the ASF >(votes, ICLA, software grant, IP clearance...). >As for the integration: additional dependencies are usually a reason for >discussion, especially if the dependency is only needed by an optional >component that not everyone uses. I personally like to keep such >components in a separate module from the core producing its own JAR so >only the people who want that functionality need to look into any >additional dependencies. After all, Batik is nicely extensible. People >would simply add the transcoder JAR and POI to their classpath and >they're ready to go. And that works just the same if you started out on >Google Code, for example. >Going lightweight for now would also allow you to gauge interest in that >functionality inside the community and you have full control over the >repository while you improve the code. The road is definitely not >blocked for your component to be integrated into Batik at a later point. >Take FOP's AFP output functionality, for example: it started out as a >SourceForge project and later got integrated into FOP when there was >enough interest. >Although our mills run slowly in the XML Graphics project, I can assure >you that we're aware that we've got a resource problem among the >existing committership and we're looking into ways to improve that. >Please be patient und keep nagging. There's certainly no ill will behind >this just in case you think that. HTH >>On 10.08.2009 13:09:45 herve.girod wrote: >> Hello, >> >>This message is linked with RFE 47491 on bugzilla (Export SVG toPowerPoint >>using POI library). There were no comments for it, so Irepost my main >>question about it here on the mailing list, mainly forthe core developers of >>Batik. > Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
