> I'm sorry. > I think I fell into a fixed idea because of my good looking results. > > Now, I'm trying to combine the advantages of both codes. I think I will reuse > the idea of a lot of existing code.
A few important things to keep in mind before I go into algorithmic ideas. The strength in the FreeType sense is how many pixels are added to a stem, half a pixel on each side, measured in 1/64 of a pixel. This is documented and expected. We cannot change that. You refer to MS implementation. Is it documented somewhere? Also you should be careful with modifying metrics. So that you do not surprise people who use this functionality. I doubt that there is an easy way to solve artifacts with a simple cap on shift. This mathematical problem has a proper rigorous solution: 1) Emboldening does not change the orientation of segments, it only changes their lengths. The "cross" situation is when the length becomes "negative" or the segment points in the opposite direction. Such segments should be removed from the *original* outline: two original adjacent segments should be shortcut at their intersection. This process might be recursive until all "cross" conditions are removed. 2) Shift the remaining simplified outline points. 3) Deal with sharp angles: use round or bevel line join. Of course this is easier said than done. I put that on hold a long time ago. You welcome to work on this. This might be a cool summer GSoC project. Regards, Alexei _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
