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

["Dave Pawson" <dave.pawson@gmail.com>]

2008/6/30 Thomas Zander <zander@kde.org>:
> There is a difference between different odf-features.

> 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.

How would you define an objective test for measuring +-2pt?
Is that practical?
This seems to be moving towards 'pixel perfect' which seemed
to be impractical.


>
> 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.

So we need a clearer definition of visual equality (your 'correctly')
Or do you see this as being based on each single atomic test?
This one we can do, that we can't?


>
> 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 ;)

That's how to implement.
Not in scope IMHO.


>
>> 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.

-1
If it's not in the spec it's a spec problem as I see it.
Either it's not tested (correct 'initial' reaction IMHO)
or a test is proposed with some proposal for a spec change
against which a test is possible within our interpretation of intent.
I doubt the main TC would like this.


>
> 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.

I don't know the spec well enough to say if it defines linebreaking algorithms.
Is this a case of application profile constrained? I.e. inapplicable on a PDA
version of ODF  text? Applicable for Koffice/OpenOffice etc?


If we can call up typography references without it being in the spec
we can call up anything?
-1

If the spec is weak it needs clarification.
If you want shared linebreaking across implementations surely
it should go to the main TC?

regards




-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk