Hi,
We had report of regression in GTK markups rendering in Ubuntu precise,
(i.e ulabel/u would render underlined), I've tracked the issue to
that commit:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=b0962ac34e66052ccfee7996e5468f30d4bd5a72
It turns out that same commit
We had report of regression in GTK markups rendering in Ubuntu
precise, (i.e ulabel/u would render underlined), [...]
We have reverted that commit in Ubuntu for now to workaround the
issue but I would like to know how to determine if that's a bug in
freetype or if other part of the stack
Werner LEMBERG wrote:
We had report of regression in GTK markups rendering in Ubuntu
precise, (i.e ulabel/u would render underlined), [...]
We have reverted that commit in Ubuntu for now to workaround the
issue but I would like to know how to determine if that's a bug in
freetype or if
On Tue, Apr 3, 2012 at 9:05 AM, Peter Hurley pe...@hurleysoftware.com wrote:
Werner LEMBERG wrote:
We had report of regression in GTK markups rendering in Ubuntu
precise, (i.e ulabel/u would render underlined), [...]
AFAIK, the problem is in gtk. For years, FreeType had this metrics
Yes. This is what the TrueType standard mandates for bi-level and
grey-level glyphs. Note that ClearType is *not* implemented in
FreeType yet! As soon as this happens, the situation changes.
BTW, section 3.3.2 in the document below gives a nice description of
fractional advance widths and
