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

List:       koffice-devel
Subject:    Re: Precision (Re: koffice/kpresenter)
From:       David Faure <faure () kde ! org>
Date:       2004-04-24 19:51:06
Message-ID: 200404242151.07108.faure () kde ! org
[Download RAW message or body]

On Saturday 24 April 2004 21:06, Nicolas Goutte wrote:
> On Saturday 24 April 2004 19:37, David Faure wrote:
> > Laurent wrote:
> > > Openoffice store into its global unit (for example if user used "mm" as
> > > default all it stored into "mm")
> >
> > Interesting. Maybe we should do this too. It makes it easier for people to
> > read the XML, if the unit being used is the same as the one in the GUI.
> 
> Be careful!
> 
> KWord uses internally points, so it should write in points. (Otherwise you get 
> easily rounding problems, especially if you go back and forth between a user 
> using mm and one using inch.) 

Hmm, you might be right. Although conversions "user-given value in mm"
 -> points -> "mm [rounded]" should be okay since we keep the full precision in the pt value 
and we then use some rounding for the mm value to avoid things like 1.000000001.
Given that we limit the precision that the user can give (to something still
quite fine-grained of course, but not completely unreasonable), I thought it
was a working two-way conversion... Difficult to prove, but let's see with one example.

I'm using the conversion values from koUnit.h:
#define POINT_TO_MM(px) ((px)*0.352777167)
#define MM_TO_POINT(mm) ((mm)*2.83465058)

#define POINT_TO_INCH(px) ((px)*0.01388888888889)
#define INCH_TO_POINT(inch) ((inch)*72.0)

If the user chooses 1mm,
the application converts it to 2.83465058pt
Now when displaying this value in the GUI, or when saving to the file,
we convert it to mm again, which gives 1.0000000010473069mm,
but KoUnit::toMM() rounds it to 0.0001 millimeters (who can distinguish
a ten-thousands of millimeter, even with a magnifier?), which gives us 1mm again.

Now if I give that file to someone using inches, on loading the application
will get 1mm -> 2.83465058pt, displayed in the GUI by converting to
0.039370146944447591 inches and rounding this to 0.00001 inches, i.e.
"0.03937 inches". When saving again, he'll save that, i.e. "0.03937in"

The first user will read that, and convert it to 2.83464pt. In the GUI (and in the file)
this becomes 0.99999626866487989mm, which is rounded to 0.0001mm again,
becoming 1mm again. Which means he would save "1mm" again.

The idea is that the "very small" rounding errors due to converting, are nothing
compared to the "somewhat bigger" rounding that is done anyway, when
displaying the internal value to the user (e.g. rounding to 0.0001mm or 0.00001in).

I'm not sure what to conclude here :)
This example works, but it shows that the level of the "just before displaying/saving"
rounding is quite important, and maybe all units haven't been given a similar
level of rounding, so some cases might not work.

Anyway... I agree with saving in pt to simplify the matter and potentially avoid
some trouble, but I wanted to prove above that at least the "store everything in pt"
mechanism (unlike KOffice's initial "save everything in 3 units" mess) is ok,
when it's only about unit->pt->unit conversions.

Everyone ok with xmlWriter.addAttributePt() then?

> If KWord would store its values in other units, then yes it should generate 
> other units. (That is something I would like to add for the unit widgets, but 
> it is not in it now and I do not consider it a priority for KOffice 1.4 
> either. (We have enough other problems.))
Agreed.
Actually I don't think I'd ever want to go that way. The memory requirements
would increase (every stored value becomes value + unit), the number of 
computations in time-critical paths would increase (converting lots of values 
to pt all the time, e.g. on every repaint/relayout).

My idea with the unit widgets was more to be able to switch the unit in the
GUI, to be able to choose which unit fits best for a given parameter,
but still with an internal storage in pt. This would allow people to e.g. enter
linespacing between paragraphs either in pt or in mm.

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]