> 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 > 0x10000L. I propose that instead we scale F_dot_P down by 0x10000L > 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