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 Mon, Jun 30, 2008 at 8:19 PM, Thomas Zander <zander@kde.org> wrote:
> 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 :)

Sorry to say 2pt does not equal 0.7 millimeters   0.70555... Forever.
0.00555... Round down does not appear to be much.  Until you wake up
to something  2pt 2/72 of a inch. 600 x 600 dpi.  = 16.66666... dots
on paper.  Compared to 16.5354331 if you go for .7 mm  So one rounds
up and one rounds down maybe.  Or do both round the same way?   Now
this gets worse if this is a stacked error.  A4 is 297 mm long.  So if
you have 2 pt moves all the way down a a4 page it is about 424.
Rounding error of + or - 1 * 424= + - 424 dots on page.  Or a aprox
movement of 18 mms over a single page.   Now that is going to expand
up. So by the 18 page of a document print you are a page out.  What is
not that large of a document really.

We really need stacking math errors forbin.

Issue is more rounding and stacking of rounding errors.  How is the
maths to be done.  What are permitable exceptions.

How do you test this dead simple a continual block of text about 20
pages long in 1pt with 1 pt space between lins no page breaks other
than software generated.  Margins set exactly so the blocks of text
should be on page.  Have program print it if its drifted from where it
should be you know the program has a issue.   Being more complete page
in lenth out is kinda a big give away to using working on top of
rounding error. 20 pages is 2 complete pages out.  To save on trees
this don't even have to print to a real printer.

My main issue is not pixel perfect.  More how badly are you going to
screw up rendering my document.  If a bit of text is a few pixels out
and nothing has driffed around due to rounding errors stack on top of
each other I am not really going to care.   Note these rounding error
stacks can also stuff up left and right nicely that also effects the
length of text.  The one long block of text is going after nice big
rendering error.   Same can be done with other parts of odf..

Peter Dolding

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