- From: Mikko Rantalainen <mikko.rantalainen@peda.net>
- Date: Fri, 04 Mar 2005 15:15:29 +0200
- To: Allan Sandfeld Jensen <kde@carewolf.com>
- CC: www-style@w3.org
Allan Sandfeld Jensen wrote: > On Friday 04 March 2005 10:10, Mikko Rantalainen wrote: > >>The thing is, you MUST NOT round the layout coordinates while >>computing "width" or "height". The correct method is to use floating >>point numbers for top,left coordinates and then do > > When will people stop this "floating point" nonsense? There is absolutely > nothing you need floating points number for to solve this. All you need is a > fixed point. For instance using 30+2 bit fixed point could solve the 50%+50% > or 25%+25%+25%+25% issues (because any one sub-pixel error would be Fixed point math can only approximate the real value, just like floating point. 2 bits for fixed point cannot handle all cases where one has more than 5 elements to compute positions/sizes for (because 2 bits can express only 4 different states). With floating point, the number of elements that causes problems because of inaccuracy is higher (because floating point MAY use more bits for non-integer part), but the problem is still there. Using just integers everywhere instead of fixed point or floating point math causes problems in some situations with 2 or more elements. The real point of my post was that current UAs are doing css_box.bottom_right_corner_x = round(left) + round(width) instead of css_box.bottom_right_corner_x = round(left + width) [where left and width are fixed point or floating point numbers and css_box.bottom_right_corner_x is an integer.] and as a result, one sees gaps between multiple side-by-side boxes. It really doesn't matter if you use floating point or fixed point. Sooner or later you have to convert to integers to render on the screen and if that conversion is broken by design, increasing accuracy in previous steps isn't going to help any. -- Mikko
Received on Friday, 4 March 2005 13:15:33 UTC