[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: RFC: Rationalising millimetres/points/inches
From:       "Shaheed Haque" <shaheedhaque () hotmail ! com>
Date:       2000-12-28 17:45:01
[Download RAW message or body]

Thomas, Waldo,

I'm aware that the proposal I just posted does not address storing the extra 
values. However, I believe that those values are essentially bogus anyway 
because:

1. the fact that any practical layout engine will operate in one unit only.

2. The illusion of precise handling of alternate values which is given by 
the technique of storing the extra values can be simply blown away by the 
user switching the UI preference from "in" to "mm" and back.

My suggestion is to maintain a precise core, and handle all conversions in a 
consistent fashion for both file and GUI I/O. The latter is accomplished by 
selecting an appropriate maximum precision for the base unit, and making all 
other values an order of magnitude more precise when stored internally.

>From: Thomas <zander@xs4all.nl>
>Reply-To: koffice-devel@master.kde.org
>To: koffice-devel@max.tat.physik.uni-tuebingen.de
>Subject: Re: RFC: Rationalising millimetres/points/inches
>Date: Thu, 28 Dec 2000 14:28:06 +0100 (CET)
>
>Something every good developer knows (or should know ;) is that you
>use one dimention for all your values, and from there you convert stuff to
>and from when you need another dimention. This is what Shaheed showed.
>
>To rationalize this very abstract sentence;
>Kword uses points internally (because they are the smallest, and thus the 
>most
>precise). This is the format it saves to file and reads from file. I don't 
>care
>if you omit the others. When the user types a dimention in milimeters it is
>converted to points for internal representation.
>
>The value the user typed, however, is saved as well as the internal value.
>The next time the user sees the same value in mm it is not converted from 
>points it
>is the same value the user typed before, this saves you from the convertion 
>problems
>Waldo mentioned.
>
>The solve, naturally, is that we make one value the value the filter people 
>create,
>the other values are extra values used to eliminate rounding problems. The 
>nice thing
>is that this has allready been done, just not visually in the DTD.
>
>We could change the DTD to reflect this behaviour better like this XML 
>shows:
>
><VALUE points="90.1234">
>     <EXTRAVALUES mm="100" inch="40"/>
></VALUE>
>
>Or something like that.
>
>
> > On Wednesday 27 December 2000 14:46, Shaheed Haque wrote:
> > > Now, using double arithmetic gives us way more range and precision 
>than
> > > anything koffice is likely to care about (famous last words), so if 
>you
> > > think this is likely to be a problem, I'd be happy to consider 
>rounding all
> > > the MM_TO_xx conversions to say 3 decimal places on input. Does that 
>make
> > > sense?
> >
> > Hmm... if you have 0.09999998 inch you can present it like 0.1000 but 
>you
> > must take care that these rounding errors don't accumulate. E.g. if you 
>would
> > present 0.66666666" as 0.667" in an input field, do you continue after 
>wards
> > with 0.66666666 or 0.667? If you present it as inch it will both be 
>shown as
> > 0.667, but when you then present it as mm, the original will be shown as
> > 16.933 while the rounded one will end up as 16.942. Can you guarantee 
>that
> > such an effect doesn't grow with each step?
> >
> > In the color dialog there was a similair problem with RGB and HSV 
>colors.
> > When you moved a slider to change the H value, the S and V values 
>changed as
> > well because of rounding errors while converting back and forth from HSV 
>to
> > RGB. The solution was to store both the RGB and HSV values and update 
>both.
> > That way it was guaranteed that setting a RGB value and reading it back
> > always gives the same result, just as setting a HSV value and reading it 
>back.
> > The only thing that isn't guaranteed is that setting a RGB value and 
>then
> > reading and setting the HSV value (unchanged), doesn't change the RGB 
>value.
> >
> > I'm expecting that you would get more stable results by storing the
> > "authoritive" unit (inch, mm, point) and then to derive other units 
>if/when
> > you need them.
> >
>
>--
>Thomas Zander                                            
>zander@earthling.net
>The only thing worse than failure is the fear of trying something new
>_______________________________________________
>Koffice-devel mailing list
>Koffice-devel@master.kde.org
>http://master.kde.org/mailman/listinfo/koffice-devel
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread]