> *Please elaborate. It's not clear to me what you are referring to, and* > *what the problem is about.*
If you checkout this (https://i.imgur.com/hw4vrZL.png) which is an ascii character `0' at pixel size 31, you can see that fixed point deviates from the actual path slightly, which does not happen in case of float. Moreover in some glyph (eg: https://i.imgur.com/aLmMPld.png) you can see that there are jagged edges. This happens because of underflow, if you check the `solve_cubic_equation' function ( https://github.com/preversewharf45/freetype2-sdf/blob/dcedba69423fc169a9ca95b6391902e1cf27e0b6/src/sdfgen.c#L490 ) there is a term `q3' which is cube of term `q'. So, in cases where is `q' is pretty small `q3' becomes zero. And later in the algorithm we have to take the `cube_root' of the term (q3 + r2) to find the final roots. Now because of underflow the impact of `q' on the final output is zero. That is why the roots davaiate and we get a wrong value. In some cases the deviation is quite high. I can perhaps increase the precision in case `q' is pretty small, or simply use Newton-Raphson similar to the cubic curve case. > *And if there is still some time left for GSoC I suggest that you* > *explore how to implement overlapping removal in FreeType, based on the* > *Skia code as Behdad suggested.* I would certainly love to do that even after GSoC. Thanks for your explanation of the motive behind using fixed-point and the summarization. Most of the things are clear to me now, I will start writing the code as soon as I figure out how to add a new module. Anuj
