On Monday 30. June 2008 09:14:43 Dave Pawson wrote:
> > Now, what specifies a passing test should be separated into several
> > points, since applications typically can pass one and fail another. I
> > suggest these points to be something along the lines of
> > a) Loading the test data and displaying it on screen (correctly ;)
> > b) Saving the loaded document out again and not loosing information.
> > c) Having GUI to alter the ODF feature to all the supported values.
>
> 'displaying it on screen correctly'?
>
> Did you read the threads on pixel perfect/display perfect?
Yes, I did.
There is a difference between different odf-features. Clearly having
align-justified as a supported feature is not really that hard. It either
works or it doesn't. Weather the right font is used, or the font-kerning is
on etc etc is not part of this ODF-feature.
Then we have features like table borders, in OOo (at least 2 years ago, when I
tested it) table borders were drawn above the cell-separator while in the
spec it was suppost to on the cell separator. So a border of 2pt was drawn
1pt too high up.
This kind of details certainly can be tested and marked as wrong; they are in
the spec.
So, the quality of the text-rendering engine is certainly an issue that
affects the quality of the overall experience. But I am convinced it is not
up to the ODF conformity people to check this.
Next to that, there is a nicely licensed library to do so called 'text
shaping' which is a major reason for the differences. If more odf
implementations can reuse this component, the problem will mostly solve
itself ;) This library is called HarfBuzz and gtk's Pango and the Qt library
already share it. Feel free to open a bugreport with OOo to make them use it
too ;)
> I've yet to see a definition of 'correctly' as used above that falls within
> ODF specification. We couldn't come up with it. If you're taking the same
> position can you define it Thomas?
Two parts (all IMOHO);
* as far as the spec is detailed, this should be fully supported in the
implementation. See the table-border example above.
* I think it makes sense to test individual ODF-features. Not a whole document
with a hundred features and test if it doesn't match up.
Where there is ambiguity in the specification (for a specific feature) we just
need to be correct against things like typography rules or other relevant
external specifications.
See also this part of my original mail;
> For interoperability [feature testing] will get you a long way,
> but there are lots
> of implementation details that may not be covered by the feature matrix.
> One good example is the basic of linebreaking. See
> http://www.kdedevelopers.org/node/2262 for some research I did on this
> topic in the past (sorry, image links broken)
> The correct typographical (in case of text) or otherwise correct displaying
> of a certain concept warrents a separate set of tests.
--
Thomas Zander
