> *Ok. This means that square-distance might need [...]* I agree that 181 is enough in a typical SDF grid, and anyway if we generate a 8bit SDF bitmap it won't be able to represent more than 127 signed values. And I also agree that closer distances are more important than distant distances if the user is simple using the SDF from simple reconstruction. But, if we want to generate something like this: ( https://www.ronja-tutorials.com/2018/11/17/2d-sdf-combination.html ) then I think both types of distances are equally important. By truncating do you mean normalizing in a range of [0, 181] or clamping the values? In both cases I don't see any problem.
> *As I said above, the distant grid points contain [...]* So, basically we subdivide the curve into small lines and use them to generate the SDF, so as to make the process faster. I will try to implement this tomorrow and see how it looks. And if it works here is what I propose: First for the squared distances. While generating SDF, I am using a `spread' parameter which defines the max distance which will be present in the final output (basically the output will have a range [-spread, spread]). So, In case the spread is small (< 181), we can use the squared distance to generate the SDF. And in case it is greater than 181 we simply use `FT_Vector_Length'. Second if the subdivision method works and is both faster and doesn't differ much from the method I am currently using, then we will use it to generate SDF if the glyph size is small, because I think if the glyph size is large then there might be too many subdivisions and it will make the whole process slow. And if the glyph if large then we will use the current method. (of course this will depend if the subdivision method doesn't differ much from the actual SDF) So we use separate implementations depending on the spread and the size of the glyph. How does it sound? > *Looks alright, including modules.mk <http://modules.mk>. Have you checked if it compiles? * Thanks for checking it out. Yes, it does compile, Anuj