Re: [ft] The fastest way to query size of a rendered bitmap

[Werner LEMBERG]

> Still, even with the most recent version:
> 
>   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}
> 
> I ran the program through shell script for 583 fonts, and DejaVuSans
> is the only one that has this issue (at least on 100 pt).

[DejaVuSans.ttf version 2.37]

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.

You should report this to the DejaVu people.


    Werner