Hi,
Fred Kiefer wrote:
Sorry, you only show these values for the first iteration. In a loop we need to
see whether these values change or not. Most likely the second iteration has
the exact same values. In that case we are looking at a rounding issue. It
seems like ascender plus descender are bigger than line_height, but when
assigning this sum to line_height this condition is still true.
It is not the first iteration, it is the hundreth or so, I leave running
and then break and copy what I see. It is difficult to know in the
console flow "when" the loop begins amidst all the printouts.
Ascender + Descender differ from line height here only by 0,00001
this is after a couple of seconds:
2015-01-19 00:19:35.047 Ink[322] 2-WantLineHeight a:10.285714,
d:2.571429, y:0.000000 | lineh: 12.857142, maxl: 0.000000
2015-01-19 00:19:35.050 Ink[322] f_ascender: 10.285714
this is after a couple of minutes
2015-01-19 00:26:04.893 Ink[322] 2-WantLineHeight a:10.285714,
d:2.571429, y:0.000000 | lineh: 12.857142, maxl: 0.000000
2015-01-19 00:26:04.896 Ink[322] f_ascender: 10.285714
it is exactly the same
Could you please first verify whether this is true and next find out if your
computer uses float or double for CGFloat? The next step might then be to get
David to look at the assembler code the macro gets converted into.
How do I know what CGFloat is? being 32bit I suppose float, but where do
we configure that?
I added this in the Macro:
if (__new_height > line_height) \
{ \
line_height = __new_height; \
NSLog(@"lh = %f, h = %f, gt? %d", line_height, h, line_height >
h); \
COMPUTE_BASELINE; \
goto restart; \
} \
this is the output (other log removed):
2015-01-19 00:39:12.193 Ink[1887] lh = 12.857143, h = 12.857143, gt? 0
Riccardo
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
