Bug 50848 - Seams with disjoint composite
Summary: Seams with disjoint composite
Alias: None
Product: DejaVu
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Deja Vu bugs
QA Contact:
Depends on:
Reported: 2012-06-07 09:41 UTC by Behdad Esfahbod
Modified: 2012-06-27 17:33 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Description Behdad Esfahbod 2012-06-07 09:41:32 UTC
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.

Comment 1 Behdad Esfahbod 2012-06-07 15:00:08 UTC
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

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"/>

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">
      <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"/>

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 name="uni259D" xMin="787" yMin="532" xMax="1593" yMax="1576">
    <component glyphName="uni2596" x="807" y="1044" flags="0x1004"/>

Both have the flag 0x1004, meaning that the offsets are rounded to the

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

I wonder how such glaring problems can be part of one of the most used
free fonts.

Comment 2 Denis Jacquerye 2012-06-27 17:33:57 UTC
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.