[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 <firstname.lastname@example.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