Hi Michael, Please note I'm using the plain (non-cairo) GTK backend. Going on what I found in the code it should have the same display effect as the riscos backend. The lines between the cells were originally yellow, but when copying screens to my windows box they changed to red. I haven't investigated it yet, but my guess is that they are initialized colour values that use alpha channel. The lines should not be visible as they are 'holes' created by rounding errors. The fixed-point values I use have a 13 bit fraction which gives about 0.000122 accuracy. That leaves 18 bits for the integer part giving a range from -266142 to 266141. I am assuming the coordinate range is -65536 to 65535 which leaves some safety margin for overflow errors during intermediate calculations. I do not know what the specs say about coordinate and sizing ranges. In the plotter functions I added code which snap the coordinates to the display pixel grid. I have found in the rendering code extra calculations for scaling, but it originates as being zoom. I feel that zooming should be done by the plotters, not by the layout/renderer. Besides, delaying scaling increases accuracy. Attached the HTML. Sorry about forgetting them in the first place. I also have to note that although the effects look promising (more accurate and no FP operations) there is a drawback. It is fixed point arithmetic and because of that you can apply any integer operation onto it. Extra discipline is required that fixed point calculations only involve proper scaled integer values. Sadly, C and GCC do not have the ability to validate this requirement. Luckily, validity can be achieved by using the operator overloading capability of C++. This implies that at a given moment, the source has to be pulled through C++ to verify proper fixed-point arithmetic usage. Franz.

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.