Mailing-List: contact batik-dev-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: batik-dev@xmlgraphics.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Sat, 15 Aug 2009 09:22:16 +0200
From: Jeremias Maerki <dev@jeremias-maerki.ch>
To: batik-dev@xmlgraphics.apache.org
Subject: Re: Export SVG to PowerPoint using POI library
In-Reply-To: <33507952.233861249902585286.JavaMail.www@wsfrf1121>
References: <33507952.233861249902585286.JavaMail.www@wsfrf1121>
Message-Id: <20090815084716.3708.60BA733C@jeremias-maerki.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

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 to PowerPoint using POI library). There were no comments for it, so I repost my main question about it here on the mailing list, mainly for the core developers of Batik.
> 
> This RFE asks to be able to convert SVG to PowerPoint documents. Basically a
> SVG document would become one slide in a PPT document. This capability would
> also allow as some cool side effects:
> - being able to get WMF and EMF images (because PowerPoint allows conversion to
> EMF and WMF)
> - being able to create "natively" a PPT document from a SVG image for people who
> want to use EMF and WMF just to get a PowerPoint document at the end
> - interoperate with programs such as OpenOffice which are able to read
> PowerPoint documents.
> 
> I have a working copy of a SVG => PowerPoint transcoder, using
> Apache POI HSLF classes in scratchpad (last POI Beta version). I could not use
> the PPGraphics2D which comes with the HSLF package (however using this class
> fired no exceptions, but the result was very incorrect, though I don't know if
> it comes from the maturity of this class, the way I used it, or even specific
> Graphics2D features that were heavily used by my -rather complex- SVG examples
> and not supported yet). It turned out I created a new PPTranscoder class,
> associated with a specific PPTGraphics2D (of course).
> 
> I have no problem to give this code to Apache (I already filed a contributor
> agreement some time ago and sent a lot of patches for the WMF => SVG
> conversion), as it can be useful to others, but apart from the fact that I
> surely have to perform more tests, I really don't know how to integrate it in
> Batik (it uses a part of POI). My question is not a "technical" question on how it is feasible to do it, but on if it can be interesting for the batik project and how (core batik code, "scratchpad" type code, etc...)
> 
> POI is under Apache 2.0 like Batik. The problem is I don't know what is the
> best way to 'integrate" POI library with Batik in order to provide this
> functionality without making Batik dependent from POI at the end (and even if
> this is really possible to do this cleanly).
> 
> Regards,
> 
> Herve Girod
> 
> 


Jeremias Maerki


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