On Wed, Jun 11, 2008 at 3:53 PM, David Gerard <> wrote:
2008/6/11 <>:
> From the study I've done of the topic, the greatest source of visual
> interoperability problems today, with the ODF implementations out there, is
> not from any defect in the ODF standard. It is caused by incomplete/partial
> implementations of the standard, where a particular feature is implemented
> partially, or not implemented at all. With the way document layout works, a
> small failure in a single feature can have a global effect in the document,
> shifting lines, pages, figures, around. Small failures can make a large
> difference. This is a kind of problem that lends itself well to testing, to
> profiling and to working with vendors toward improvements.
Do you or someone have a list of these? Sounds like an excellent start
on an ODF Acid Test. And, of course, a good checklist of what features
an ODF writer needs to implement in what order.
Indeed an acid test in the form of a (multi-page?) document with progressively complex/esoteric directives could be a useful device for 'naming and shaming' poor implementations, as has proven very effective for W3C standards. It will be interesting to see if there is a place for something like this alongside a more complete test suite, or indeed if there is even a need for both (presumably the former will enjoy more eyeballs which is arguably a good thing, if it can be brought up to the task).
This should be a lot easier for spreadsheets (at least formulas) where a green/orange/red matrix could be set up, potentially with each field dependent on the last based on implementation priority. Acid3 appears to do something like this (eg I just got 71/100 on FF3rc2).
Sam
