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

List:       koffice-devel
Subject:    Re: RFC: Rationalising millimetres/points/inches
From:       Thomas <zander () xs4all ! nl>
Date:       2000-12-28 18:25:09
[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.

Agreed.

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

Good point. It does not make my points moot, but the current concept is so
hard that I think this will work better in the end. Just make sure that the conversion 
code (which converts to/from the internal to the gui) works very good. I hate 
to see rounding errors in the gui.  (when for example I type 300mm in paper 
size and get 299 next time I open my dialog..)

Always do rounding on doubles and I think it will work fine;
  int points = (inch * 2.54 * 72.0) + 0.5;
 
> 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.

Agreed. Overkill is not really a problem for me. "%.5f" looks good to me for 
saving to the xml.

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

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