Re: OOXML [was Re: GNOME Foundation Board Meeting Minutes :: 7/6/07]



On Wed, Oct 31, 2007 at 08:52:51PM +0000, Rui Miguel Silva Seabra wrote:
> 
> > > It is not the membership that is really detrimental, although you can
> > > bet Microsoft is spinning around that "open source likes OOXML" thanks
> > > to that.
> > People can spin things however they'd like.  I'll implement any file
> > format users request.  If people are comfortable citing Gnumeric for
> > ODF, they can cite it for OOX too.   At the end of the day, if
> > people use Gnumeric, or free software, we've won.
> 
> Spreadsheets are probably much easier to support, since they have a much
> more structured data (fixed table spaces, namely).

Spoken like a non-spreadsheet user.  My experience suggests exactly
the opposite.  Users are a lot more forgiving of kerning differences
than they are of calculating different answers.
 
> > Having worked on filters for both formats, I'll trust my judgement
> > over the various position papers with obvious biases littering the
> > net.  Both formats need work, the black and white characterization of
> >     ODF == good
> >     OOX == bad
> > does not fit what I've seen while implementing things.
> 
> Naturally, Gnumeric follows the design of Excel, which follows the
> design of it's file format, so its structure and logic are naturally
> reflected in a document format which is designed to reflect status quo.
> 
> I'd be surprised if it happened otherwise!

Neither format has been without it's irritations.  We've certainly
saved some time by reusing code from the XLS filter, but that is far
from the only reason for the disparity.  I've just wasted part of
this week trying to fix our ODF chart importer.   ODF helpfully
assigns data implicitly, without detailing how things fit together
in the data.

        <chart:plot-area table:cell-range-address="Sheet1.$B$1:.$C$4" ...
          <chart:series ...
            <chart:domain/>
          </chart:series>

Minimal information on whether B goes into X or Y.  Start adding
multiple series into 1 plot and things get complicated quickly.  To
make things even more difficult, the entire approach is wrong.
It does not allow for calculated content, or inline arrays.

Data validation is specified is another area where implementation
could have been simple, had ODF used stock xml.  Instead it decided
to store the spec as some sort of magic formula string that requires
yet another parser.

> 
> But you're actually advocating it become a standard as it is...

I am advocating that people use free software, and don't see that I
have any control over whether OOX becomes an ISO standard for MS
file formats or not.
 
> I would personally not care much if the only problem between ODF and
> OOXML were of being two standards for the same target.

That is precisely what I would have a problem with.  If MS tried to
claim that OOX was 'the one true office format', or tried to add
support for ODF extensions and 'harmonise' the specs I'd be up in
arms.  Thankfully they are not, and more importantly the politics of
the situation have forced them to explicitly state the opposite.

Contrary to the way this is being portrayed, this is a win win
situation for free software.

    Either we get more docs and MS is constrained from embracing and
    extending their standard.
Or
    MS offers up even better documentation and tries again


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]