Re: [ft-devel] [PATCH v2] Improve FT_Outline_Embolden for the unintended artifacts problem (#45596).
On Mon, 8 Oct 2018 21:38:42 -0400, Alexei Podtelezhnikov wrote: I want to hear your opinion on this approach. The original glyph shape is usually smooth: the contours have no self-intersections. The emboldening might result in self-intersecting contours. This is the main reason for majority of artifacts. You already figured out that corners slide along bisectors, assuming symmetric strength.x == strength.y. It is easy to see that self intersections happen when a segment flips its orientation under certain condition. This condition is easy to formulate but it involves both corners at the segment termini and the length of the segment. Nothing short of resolving these will work: such segments have to be removed. To put it differently, the outline has to be simplified by removing self-intersecting segments and replacing them with a point at the intersection of the flanking segments. That is it and then you apply emboldening cleanly. Yes. I was trying to do a solution this way. The problem is that this method alone can eliminate the intended design of the font. So, how about using the newly introduced shifter to implement it? k==2.3 is almost similar to the existing shifter between 90 and 270 degrees, and I think it is appropriate for the rest. The other issue is sharp corners that are left. The standard solution for them is bevel or round join of lines in the emboldened outline. This is totally separate. I do not see other reasons for artifacts and very much doubt that any easier solution exists. By the way, we has glyph stroker https://www.freetype.org/freetype2/docs/reference/ft2-glyph_stroker.html. This should be a sister algorithm, but it is implemented separately with a bunch of trigonometry. I personally would love to have a single FreeType module handle both, implemented using bisectors. So this is a big project altogether: I would estimate at least 100 hours of programing. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [PATCH v2] Improve FT_Outline_Embolden for the unintended artifacts problem (#45596).
> I want to hear your opinion on this approach. The original glyph shape is usually smooth: the contours have no self-intersections. The emboldening might result in self-intersecting contours. This is the main reason for majority of artifacts. You already figured out that corners slide along bisectors, assuming symmetric strength.x == strength.y. It is easy to see that self intersections happen when a segment flips its orientation under certain condition. This condition is easy to formulate but it involves both corners at the segment termini and the length of the segment. Nothing short of resolving these will work: such segments have to be removed. To put it differently, the outline has to be simplified by removing self-intersecting segments and replacing them with a point at the intersection of the flanking segments. That is it and then you apply emboldening cleanly. The other issue is sharp corners that are left. The standard solution for them is bevel or round join of lines in the emboldened outline. This is totally separate. I do not see other reasons for artifacts and very much doubt that any easier solution exists. By the way, we has glyph stroker https://www.freetype.org/freetype2/docs/reference/ft2-glyph_stroker.html. This should be a sister algorithm, but it is implemented separately with a bunch of trigonometry. I personally would love to have a single FreeType module handle both, implemented using bisectors. So this is a big project altogether: I would estimate at least 100 hours of programing. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Rendering issues with xpdf (and other Linux based pdf viewers)
On Sun, 07 Oct 2018 21:42:19 +0200 (CEST) Werner LEMBERG wrote: > > Btw, been wondering if something could/should be done on freetype > > too - while we know where the broken hinting instructions came about > > in this case, similar problem can come from a different source > > too. > > People can always run the hinter in paranoid mode, rendering a glyph > without hinting if an error is returned... Can you elaborate on this? How does one run the hinter in paranoid mode? I'm wondering if it would be possible/useful to do this in Xpdf (or at least provide an option to do it). - Derek ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
