Hello All,
*> Have you figured out FT_Fixed arithmetic? You still use floats in your > code. I think you should convert to FT_Fixed first. * So, I have been trying to convert my code to FT_Fixed for a few days now without any success. I did manage to use fixed point for shapes with only line segments, but because of small range of 16.16 fixed point I have to use 26.6 for intermediate calculations and because of that it doesn't look good, (https://imgur.com/kUSIj3y) Here is a comparison between float on the right and 26.6 fixed point representation on the left. As for bezier curves, there is almost always an overflow because while solving polynomials some large numbers are involved. I even tried using Newton's approximation, but it's too slow and still not as accurate as floating points. I did not try using 64 bit integers because they are not portable I guess and because of that I have to create separate implementations for 32 and 64 bit architecture. So, after comparing both, I prefer floats over fixed points because they satisfy both range and precision. I can try using 64 bit integers but I am not sure whether I will be able to finish the project on time or not because of separate implementation. I have attached the code below, note that this is my first time dealing with fixed points so there might be something that I am not doing right. SDF with fixed point: https://github.com/preversewharf45/freetype2-sdf/tree/FT_Fixed You can directly go here ( https://github.com/preversewharf45/freetype2-sdf/blob/FT_Fixed/src/sdfgen.c#L579) to see the important changes I have made. To view output: https://github.com/preversewharf45/freetype2-sdf-demo (already has sdf code) Anuj On Mon, Jun 1, 2020 at 7:18 PM Alexei Podtelezhnikov <[email protected]> wrote: > Hi Anuj, > > > I have written the program, you can find it at: > https://github.com/preversewharf45/freetype2-sdf > > To view the output I'm currently using a small OpenGL framework: > https://github.com/preversewharf45/freetype2-sdf-demo > > this already has the sdf code. > > I like the style. Looks good. > > > However there is an issue with the program, the glyphs which contain > intersecting contours have an issue. > > (example: https://imgur.com/MxJfAwY) > > The intersecting contours used to be discouraged and still quite rare. > In general, you should assume that fonts have reasonable shapes > without intersections or wrong contour orientations. It is more > important that your code deals with thin stems and cursive fonts with > tiny details like serifs. > > > Currently the sign of the distance is determined by the orientation of > the closest edge, so at places where > > one contour intersects another the pixel near that contour can be > specified as outside even though it is > > inside the shape. > > To fix this issue I'm thinking of using the winding of the contours, so > is there any function in freetype > > to get the winding or something similar? > > We only have > https://www.freetype.org/freetype2/docs/reference/ft2-outline_processing.html#ft_outline_get_orientation > You can cut the outline into individual contours manually. Keep in > mind that the orientation is different for TrueType and Type1/CFF > fonts. > > > Also, should I start integrating this in freetype or first fix the issue? > > Have you figured out FT_Fixed arithmetic? You still use floats in your > code. I think you should convert to FT_Fixed first. > > Best, > Alexei >
