Hello,
with some surprise I have seen hundrets of check ins in the CWS ooxml02
with the goal to implement OOXML export filters. For Calc this seems to
be done by extending the binary BIFF export filter. As it looks this
makes it necessary to export headers from and linking against oox thus
On Fri, 2008-11-21 at 11:57 +0100, Daniel Rentz wrote:
with some surprise I have seen hundrets of check ins in the CWS ooxml02
with the goal to implement OOXML export filters. For Calc this seems to
be done by extending the binary BIFF export filter. As it looks this
makes it necessary to
Jonathan Pryor schrieb:
On Fri, 2008-11-21 at 11:57 +0100, Daniel Rentz wrote:
with some surprise I have seen hundrets of check ins in the CWS ooxml02
with the goal to implement OOXML export filters. For Calc this seems to
be done by extending the binary BIFF export filter. As it looks this
Daniel Rentz schrieb:
Jonathan Pryor schrieb:
On Fri, 2008-11-21 at 11:57 +0100, Daniel Rentz wrote:
with some surprise I have seen hundrets of check ins in the CWS
ooxml02 with the goal to implement OOXML export filters. For Calc
this seems to be done by extending the binary BIFF export
Hi Daniel,
On Fri, 2008-11-21 at 17:15 +0100, Daniel Rentz wrote:
1. Leave the dependency, merge ooxml02 for 3.1, and work to remove it
for 3.2+.
..
I don't like (2). I think best thing is to do (1), and think about (3)
for 3.x as you suggested.
That sounds great; just to give
On 11/21/08 18:01, Michael Meeks wrote:
That sounds great; just to give a quick rational as to why this
approach. While clearly a separate UNO component, or things living in
oox is the end-goal, I'm a fan of step-wise re-factoring - such that we
can prove that nothing broke during the
