<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Some glyphs have invalid bytecode"
href="https://bugs.freedesktop.org/show_bug.cgi?id=103836">103836</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Some glyphs have invalid bytecode
</td>
</tr>
<tr>
<th>Product</th>
<td>DejaVu
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>Sans
</td>
</tr>
<tr>
<th>Assignee</th>
<td>dejavu-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>daniel.plachotich@yandex.ru
</td>
</tr></table>
<p>
<div>
<pre>Some glyphs in DejaVuSans.ttf version 2.37 have invalid bytecode which affects
the rendering of other glyphs.
For example, if you render glyphs with FreeType in particular order, the bitmap
can be 1 px larger than expected. Here is the program to test the issue:
<a href="https://gist.github.com/danpla/35292c7c54fc1217b81219aa442dcc37">https://gist.github.com/danpla/35292c7c54fc1217b81219aa442dcc37</a>
Compile it with FreeType 2.7.0 or newer and run with DejaVuSans.ttf at 100 pt.
It will give the following:
FreeType 2.8.1
Loading DejaVuSans.ttf at 100 pt
Checking cbox vs bbox
Checking bitmap vs cbox
U+07ED bitmap > cbox: {11, 10} > {11, 9}
U+07F2 bitmap > cbox: {10, 10} > {10, 9}
U+07F3 bitmap > cbox: {30, 10} > {30, 9}
U+07F8 bitmap > cbox: {48, 50} > {48, 49}
Among 583 fonts I tested, DejaVu Sans is the only one that has this problem.
We discussed this issue on FreeType mailing list, and here is a quote from a
FreeType developer:
<span class="quote">> This is a font bug. The bytecode of glyph `uni2751' in the font is
> not fully encapsulated, causing side effects to other glyphs: It
> modifies CVT entries with indices 3, 8, 0, and 6, setting them to a
> large value (250px). However, the bytecode of glyph `uni07ED' (and
> probably the other three glyphs also) uses CVT entry with index 8,
> too: If this CVT value is smaller than 10px (the `CVT cut-in', as set
> up in this font for 100ppem), the original, rounded value gets used as
> the distance between the top and the bottom points (which is 9px),
> otherwise the CVT cut-in value gets used, which is 10px.
>
> In other words: If you load U+07ED, then U+2751, then U+07ED again,
> you get an 11x10 bitmap instead of an 11x9 size.
>
> It's not easy to say which glyph's bytecode is incorrect. In general,
> CVT values shouldn't be modified by glyph bytecode, otherwise you have
> global effects, which is undesirable in most cases – as you have
> detected. It's rather the job of the `prep' table to properly set up
> CVT values.</span ></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>