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?

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.

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?

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


Dave Pawson

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