> For testing purposes, I've slightly altered your program so that only > one glyph of zeroes_three.ttf is rendered, the dot glyph. To make the > effects really visible, I've also set nominal_pixel_height to 96 and > real_26_6_border_radius to 16*64. Attached is the resulting PNG. > However, after the call of FT_Glyph_Stroke, the returned FT_Outline > structure looks just fine (see the attached PDF as created with > MetaPost).
That narrows down what could be causing this problem, thanks! > It seems that the problem occurs later in your program, during > the rendering process: Probably an initialization bug, or a too- > small array? My "arrays" are std::vectors, which expand automatically, so they're very unlikely to be the problem. Following what you've done, I've further simplified my repro: http://stl.nuwen.net/pub/freetype/repro2.cc http://stl.nuwen.net/pub/freetype/output_new.png This uses a real_26_6_border_radius of 30 * 64, which significantly detaches the border from the core glyph. The detachment (which happens only for extremely thick borders, much thicker than is necessary to cause visible right-side glitching) appears to be caused by self-intersection of the border outline. With repro2.cc, which makes the border and core overlap visible, I tried gradually increasing the border radius, and watched it self-intersect before detaching. I'm not /very/ concerned about the detachment; I'm much more concerned about the right-side glitching. The right-side glitching appears to be a separate effect, and unrelated to my rendering process. The data given by FT_Outline_Render() to my span_func() is being accurately rendered to the BMP (or to the texture, in my original code). To demonstrate this, repro2.cc's span_func() prints out each span that it receives. Because the border radius of 30 * 64 is so extreme, the right-side glitching can actually be observed from the spans themselves. First, look at the Core spans. They range from y = -2 to y = 12. As the glyph is a circle, the widest part is at roughly y = 5. There are 3 Core spans for that row: Core | coverage 253 | y 5 | x [ 3, 3] Core | coverage 255 | y 5 | x [ 4, 16] Core | coverage 252 | y 5 | x [ 17, 17] The core glyph's right edge covers x = 17. Now, consider the border. If the outline is correct, it should be a ring (given the detachment). Therefore, its spans for the row y = 5 should have x-coordinates less than 3, and greater than 17, and should extend for a while (visually, about 14 pixels). Instead, the spans that we get are: Border | coverage 254 | y 5 | x [-27, -27] Border | coverage 255 | y 5 | x [-26, -13] Border | coverage 3 | y 5 | x [-12, -12] Border | coverage 1 | y 5 | x [ 21, 21] This *exactly* matches the rendered image; the left part is fine, while the right part is cut off (and not even in the correct position; x = 21 is too close to the glyph). Since you've determined that the border outline is valid, and I've determined that FT_Outline_Render() is returning bogus spans, either FT_Outline_Render() is buggy, or I'm calling it incorrectly (but I don't see how, and it works for the core glyph and the other sides of the border). Also - I tried this with verdana.ttf from Windows and still got the glitching, so we can rule out zeroes_three.ttf being busted somehow. Thanks, Stephan T. Lavavej _______________________________________________ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
