OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [oiic-formation-discuss] My perspective. display perferct?

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

This is a digitally signed message part.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]