Problem I reported to FreeType and Werner's response: > > I was playing with Unicode box characters, and noticed that DejaVu > > Sans creates the glyph for ▟ out of three quadrant boxes. At > > different sizes I can see very noticeable seams where the sub-glyphs > > meet. I thought FreeType would handle these cases better, but seems > > like I'm wrong. Any ideas? Does FreeType combine all contours > > together and rasterize them in one pass, or raster them separately > > and combine? They are rasterized in a single pass. However, the DejaVu font doesn't contain the necessary bytecode to properly handle the rounding issues which inevitably happen if subglyphs are combined -- in ftview, press key `f' to force autohinting, and you won't see seams. I've just confirmed that exactly the same issue is present with the Windows rasterizer, so it's not a FreeType problem. Of course, a much simpler (and probably even better) solution is to avoid subglyphs if they touch at longer lines. Werner
More from Werner: >> >> It depends on a flag in the glyph's data, ROUND_XY_TO_GRID, if the >> >> subglyph's offset is given as xy values. However, for the >> >> particular DejaVu glyph, the subglyphs all have a zero offset, but >> >> point coordinates are rounded to integers anyways as part of the >> >> normal rasterization process. > > > > Right. So I guess my question is, why are they rounded differently? I spoke too hastily since I hadn't looked closely enough at the subglyphs. It's a bug in the font. The glyph ▟ consists of three elements: <TTGlyph name="uni259F" xMin="-20" yMin="-512" xMax="1593" yMax="1576"> <component glyphName="uni2596" x="0" y="0" flags="0x1004"/> <component glyphName="uni2597" x="0" y="0" flags="0x1004"/> <component glyphName="uni259D" x="0" y="0" flags="0x1004"/> </TTGlyph> Note that the 4 in the flags value 0x1004 means ROUND_XY_TO_GRID. Now the components. The first one is a real glyph: <TTGlyph name="uni2596" xMin="-20" yMin="-512" xMax="786" yMax="532"> <contour> <pt x="-20" y="-512" on="1"/> <pt x="-20" y="532" on="1"/> <pt x="786" y="532" on="1"/> <pt x="786" y="-512" on="1"/> </contour> </TTGlyph> The other two, however, are not: <TTGlyph name="uni2597" xMin="787" yMin="-512" xMax="1593" yMax="532"> <component glyphName="uni2596" x="807" y="0" flags="0x1004"/> </TTGlyph> <TTGlyph name="uni259D" xMin="787" yMin="532" xMax="1593" yMax="1576"> <component glyphName="uni2596" x="807" y="1044" flags="0x1004"/> </TTGlyph> Both have the flag 0x1004, meaning that the offsets are rounded to the grid... The real solution is to redefine uni259F (and all other similar block characters) having uni2596 three times as subglyphs, with proper offsets, and with flags values 0x1000. I've justed tested it: no gaps. I wonder how such glaring problems can be part of one of the most used free fonts. Werner
Fixed in revision 2505. Thanks for the report.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.