Werner, Before you look at my patch can you check that those are not bugs on the following lines?
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? 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. 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. Alexei
ft-F_dot_P.patch
Description: Binary data
_______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel