Hi Adrian,
I used 13 bits for the fraction to catch the range of intermediate
values in the expressions. Reordering these expressions should reduce
these number of bits to below 8 leaving at least 23 bits for the integer
part. I deliberately chose for fractional values to relax certain
corners in the code like distributing excess space between table cells.
The current code didn't seem right and when stressing it I bumped into a
nasty cascade of bugs that I am currently fixing. There is a fair chance
that similar issues are present in other places. Using fractional values
should lead to a certain reduction in complexity and thus amount of code
and bugs.
I have a patch but I am keeping it on hold because I want the mentioned
bugs fixed first. I prefer a stable patch before an more experimental. I
also need to think of a better way of ensuring code validity as C has no
natural mechanism to handle user-defined fractional values. I currently
use C++ operator overloading and realize that switching language just
for this functionality is not an option. I expect it to be a mix of
macros and integer operations accompanied with a test-build using C++
(the target remains ansi-C) to validate all involved operands.
Franz.
I feel that zooming should be done by the plotters, not by the
layout/renderer. Besides, delaying scaling increases accuracy.
Yes, absolutely. It also means that the layout/rendering code can just
work with normal ints and have more than enough bits to handle even
very long HTML files. Your alternative approach of using fixed-point
arithmetic to keep the scaling in the rendering code would probably
run into trouble with exceptionally long files and a usable range of
only 2^18.
However, if we use normal unscaled co-ordinates throughout the renderer
and then, having already clipped to the visible area (at least for
screen output*) this is well below 2^18 currently) and then use
fixed-point arithmetic for zooming in the plotters. I'd suggest using
22.10 (or maybe just 24.8) for the plotter arithmetic since the scale
factor can only be set to n%.
Certainly it'd be great to finally eliminate the floating-point
arithmetic (this has been on my wishlist for a long time), so if you
already have a patch to do this, that's great.
Adrian
*Of course any plotters required to cope with the entirety of a long
page can simply use 64-bit quantities when they perform their scaling
and take the performance hit.
