# Re: Designs that zoom (was : Why reduce font size)

From: Mikko Rantalainen <mikko.rantalainen@peda.net>
Date: Fri, 04 Mar 2005 15:15:29 +0200
Message-ID: <42285F71.8000509@peda.net>
To: Allan Sandfeld Jensen <kde@carewolf.com>

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

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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:17 UTC