[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] a cosmetic cut-and-paste bug in the new font var code, an
From: |
Hin-Tak Leung |
Subject: |
Re: [ft-devel] a cosmetic cut-and-paste bug in the new font var code, and another issue |
Date: |
Sun, 16 Apr 2017 15:38:46 +0000 (UTC) |
--------------------------------------------
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.