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 9:26 PM, Thomas Zander <zander@kde.org> wrote:
> On Monday 30. June 2008 13:04:17 you wrote:
>> 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.
>
> In my experience this is testable per feature.  So I don't think we should
> have an extra visual concept in the TC deliverables.
>
> If you have any sort of correct WYSIWYG layout mechanism you *need* to
> conserve that 7.05555 mm instead or remembering it being 5 pixels.  Since if
> you zoom out, you already have a problem. Your 20 lines per page become 21
> lines...
> So this problem you see is not a problem for us; its a general problem in the
> implementation; it would suck at basic stuff if it did it incorrect ;)

Say hello to word and some old version of OpenOffice.  Yes they did
not get the basics correct.  Word screws up documents every time you
change printers its storing locations in printer dependant metrics.

Reason why I want it in the TC.   We are going to get shoddy WYSIWYG
and shoddy conversions to page.  Simple having the test you can say to
people that is not rendered correctly its stuff it up its the
defective one.  Worst problem is if the shoddy ones end up out
numbering the good ones.  Better to have it nailed now then latter.

Current issue read the standard where does it say they are wrong to
round that way.

As long as the evil of stacking rounding errors is tested for
somewhere in the process.  I will be happy.

Peter  Dolding


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