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

[Thomas Zander <zander@kde.org>]

On Monday 30. June 2008 11:26:03 Dave Pawson wrote:
> 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.

2 pt equals 0.7 millimeters, that's a pretty objective measurement IMOHO...
Just set the display to 100% and grab your ruler. (or 200% and measure it to 
be 1.4mm if you want it to be more accurate)

I must be missing something, since this sounds easy to me :)

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

I'm defining 'correct' as following the rules, either from ODF or from the 
specifications ODF leans on. Which includes the typographical rules.
This, in my mind, does not always equate to being visually equal because there 
are a LOT of little details to be considered.
Also, if you refer back to my initial mail I detailed a list of usecases and 
the usecase of using ODF for pixel precision text layout is just a very very 
small one compared to all the other usecases there are.
I understand that currently this is what appears important to people, but we 
should not stress the issue too much.

> > 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 agree, I just wrote this to point out that putting too much effort into 
pixel precision is not worth it. Its a technical 'detail' that can only be 
forced to be solved by using the same codebase. 

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

Not everything can be in the spec, ISO specifically states we have to reuse 
externally defined concepts and depend on those.
We refer quite often to the xslt spec for details from ODF, we don't absorb 
the spec.  So in a way its actually specified, just externally.

> I don't know the spec well enough to say if it defines linebreaking
> algorithms. 

Hmm, I see I made a typo; I meant line-spacing (leading) concepts. Not 
linebreaking algorithms.
But, no, it does not in either case.

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

Its not like there are a dozen ways to do correct typography ;) So, I disagree 
with you here.
If the specification states we do drop-caps, I just get my typography book out 
and read up on the concept to find out how to do it correctly.  In practice 
there is no ambiguity, you are just required to get the information 
elsewhere.

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

Again, I think you are focussing too much on one small usecase of ODF. The 
Office-suite part.  There are a LOT more usecases where details like 
line-breaking is irrelevant and we should keep the balance.
Or, in other words, if we focus completely on pixel precision I am sure that 
in 3 years our work is irrelevant and out of scope for most useages of ODF.

Next to that, forcing the details of linebreaking to be in the spec is akin to 
having a hashing algorithm in OOXML, it just doesn't make much sense to 
reproduce ongoing research in a specification.
I am wondering *why* you want to have something in there. Which probably means 
I am asking you the question; what do you think ODF is meant to do?

-- 
Thomas Zander

This is a digitally signed message part.