Re: [ft-devel] a cosmetic cut-and-paste bug in the new font var code, and another issue

[Hin-Tak Leung]

--------------------------------------------
On Sun, 16/4/17, Werner LEMBERG <address@hidden> wrote:

> Applied, thanks!
 
Thanks!

> I agree that
 an invalid charcode shouldn't cause an `invalid size
 handle' error.  However, it's hard to
 further comment the issue
 without having
 some demo code, so please provide something that I can
 compile and debug.
 
The python code is at

https://github.com/rougier/freetype-py

the first few lines of
examples/emoji-color.py

face = freetype.Face("/System/Library/Fonts/Apple Color Emoji.ttc")
face.set_char_size( 20*64 )
face.load_char('😀', freetype.FT_LOAD_COLOR)

The backend python code auto-converts the emoji to charcode under python3, but 
in in python2, it passes the address of the string buffer (this is a known 
internal significant change between python 2 and 3, how strings are handled 
internally) which is a large number on 64-bit platform and garbage to freetype.
I only saw the problem with FT2_DEBUG="any:7". The backend python code has 
pretty much the same meaning in in C -         

error = FT_Load_Char( self._FT_Face, char, flags )
if error: raise FT_Exception( error )

FT_Load_Char upon seeing garbage, do TT_Load_Index 0, and returns 
Invalid_Size_Handle.

I think glyph zero is a bit funny on the emoji font, but I don't know how yet.

Hin-Tak

P.S, on my fork https://github.com/HinTak/freetype-py , I have added some code 
to "do the right thing" for python2, and am trying to push that upstream atm.