We need to know whether the glyph exists, so we can fallback to
composing / decomposing. Assuming that glyph==0 means "doesn't exist"
wouldn't work for applications like Pango that want to use different
"doesn't exist" glyph codes for different characters. An explicit
return value fixes that.
I was reconsidering whether y should grow down, since all three/four
times I've used this API I was tricked and got that wrong in my use.
So I was very inclined to make y grow down instead of up. However,
considering that the font space has y up and it would be very confusing
for callbacks to work against that, I decided that what I really want
is for the user to be able to set y_scale to a negative number to imply
that user-space y grows down.
Changing x_scale/y_scale from unsigned int to int allows that, and I've
made pango to use that instead of negating glyph y_offset later. hb-ft
however still has y group up. I *guess* that's how FreeType works?
I'm not sure, FreeType docs don't make this clear...
I'm happy with the resolution :-).
The idea here is that:
- Like pretty much all other API in harfbuzz, user does not have to
check for NULL.
- In any caller code, the case of missing table should be handled
exactly the same way that a too-short table is handled. Turning
a non-existent talbe into a table of size 0 makes the user code
safer.
This was a bizzare piece of API that I inherited from cairo. It has
been wrong adding them to cairo in the first place. Remove them before
someone uses them!
One in particular is not a straight getter: hb_font_unset_funcs() is
special because of the specific needs of the lifecycle management of
the user_data object.
hb_font_set_scale() now sets the value to be used to represent a unit
pixel. For example, if rendering a 10px font with a 26.6 representation,
you would set scale to (10 << 6). For 10px in 16.16 you would set it to
(10 << 16). This space should be the same space that the get_glyph_metrics
and get_kerning callbacks work in.
Behdad Esfahbod