ttinterp.c:2706: After checking if F_dot_P is smaller than a
threshold, it is assigned a maximum possible value rather than a
threshold value. Is it possible that there is one zero too many on
line 2706 and we meant to assign a threshold value?
I think the current code is correct: If the value gets too small, use
a (possibly large) default value which essentially disables the
transformation.
ttobjs.c:767: F_dot_P seems to be initialized to a tiny tiny value
that is actually much smaller than the above threshold. It looks
arbitrary when compared to the rest of F_dot_P usage instances with
huge unscaled F_dot_P. Please check.
As far as I can see, this initialization is not necessary at all,
since F_dot_P gets always computed in line 8149 before any bytecode is
run. Perhaps a compiler has complained about a missing
initialization, and an arbitrary value (without a deeper look at the
code) has been assigned in line 767.
About the patch, whenever we use F_dot_P in the bytecode interpreter
in comparisons or divisions we have to scale up the other side by
0x1L. I propose that instead we scale F_dot_P down by 0x1L
when we assign it. This improves readability and avoids huge
numbers and confusions with number of zeros. Please review the
attached patch.
I think it's better to not apply this patch. Reasons:
(1) You are stripping off 16 bits of F_dot_P's precision. Or am I
missing something? Pixel positioning in the TT interpreter is
extremely sensitive to rounding; even smallest changes in the
code might cause pixel shifts. Maybe such fixes/changes can be
played with after we have a test suite which does a lot of pixel
comparisons, but right now we don't have one.
(2) FT_MulDiv and friends can handle 64bit precision internally, so
I don't see a problem here with large numbers. And there is the
abovementioned check in line 2706 to avoid too small values
which would make the division overflow.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
