It uses locale information to detect default language. It's used by
hb_shape() whenever language is not set on the buffer.
Not sure how to properly test it in the test suite. Tested by observing
that with DejaVu Sans we select the proper local glyph version for U+431
under Serbian locale. See http://www.pango.org/ScriptGallery
While the cluster fields of the glyph string are usually sorted, they
wouldn't be in special cases (for example for non-native direction).
Blindly using bsearch is plain wrong. If we want to reintroduce this
optimization we have to make sure we know the buffer clusters are
monotonic and in which direction. Not sure it's worth it though.
Note that the static variable has to be a global static, as gcc
implements local statics differently and that would require linking
to libstdc++, which we don't want.
The Win32 definitions for LONG, ULONG, etc conflicts with
hb-open-type.h. Avoid that by making sure hb-object-private.h
and hb-open-type.h are not included in the same compilation unit.
Now that we use C++ for all source code, lets benefit from it!
The hb_be_int16/32_get/put/eq() macros grow code size if replaced with
inline functions, so leave them as is.
Talking to Ryan Lortie, he thinks my comment doesn't make sense.
So I'm making the getter const. Note that g_atomic_int_get()
casts that away itself, so we don't need to worry about that
(which kinda makes me uncomfortable actually).
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!
Unicode data providers can now be subclassed, including support for
chain-up. The interface should now be nicely bindable, as well.
Also fix glib unicode funcs that where broken after hb_script_t
changes. Nicely caught by the test-unicode.c added in this commit.
This includes HB_DIRECTION_INVALID and HB_SCRIPT_INVALID.
The INVALID will cause a "guess whatever from the text" in hb_shape().
While it's not ideal, it works better than the previous defaults at
least (HB_DIRECTION_LTR and HB_SCRIPT_COMMON).
The problem with HB_TAG_STR() was that it expected a string of size 4
exactly, and unlike hb_tag_from_string() it doesn't pad the tag with
space characters. So, the new name is more appropriate.
Since we now assert thos in hb-private.h, the int types cannot be wrong.
(Except for when someone else includes hb-common.h in a very broken
configuration, but that's not our problem!)
Plus, we don't use inline in the public headers, so remove that too.
That better matches OpenType spec. Note that we enable it for all
Arabic-shaper scripts. Ie. we enable it by default for Syriac too,
but the SyriacOT spec does not require it. I think this is a more
useful compromise than special-casing for Arabic script alone.
The --features parsing handles errors now. More importantly, it
allos limiting individual features to specific byte ranges. The
format is Python-esque. Here is how it all works:
Syntax: Value: Start: End:
Setting value:
"kern" 1 0 ∞ # Turn feature on
"+kern" 1 0 ∞ # Turn feature off
"-kern" 0 0 ∞ # Turn feature off
"kern=0" 0 0 ∞ # Turn feature off
"kern=1" 1 0 ∞ # Turn feature on
"kern=2" 2 0 ∞ # Choose 2nd alternate
Setting index:
"kern[]" 1 0 ∞ # Turn feature on
"kern[:]" 1 0 ∞ # Turn feature on
"kern[5:]" 1 5 ∞ # Turn feature on, partial
"kern[:5]" 1 0 5 # Turn feature on, partial
"kern[3:5]" 1 3 5 # Turn feature on, range
"kern[3]" 1 3 3+1 # Turn feature on, single char
Mixing it all:
"kern[3:5]=0" 1 3 5 # Turn feature off for range
Accepts values like:
--features="-mkmk,aalt=2,calt=1,+cswh"
A minus sign means "=0", a plus sign means "=1". Default is "=1".
A minus sign overrides an explicit value.
Also adds --script support to hb-view.
If a script tag is not known to us, we pass the ISO 15924 tag around.
Right now, the OT layer ignores that, but we can fix it to blindly
convert that to an OT script tag.
- Rename HB_SCRIPT_INVALID_CODE to HB_SCRIPT_INVALID
- Add HB_DIRECTION_INVALID
- Make hb_script_get_horizontal_direction() public
- Make hb_shape() guess script from buffer text (first non-common
non-inherit script) if buffer script is set to HB_SCRIPT_INVALID (this
is NOT the default.)
- Make hb_shape() guess direction from buffer script if buffer direction
is set to HB_DIRECTION_INVALID (this is NOT the default.)
- Make hb-view.c set INVALID script and direction on the buffer.
The above changes are meant to make hb-view fairly useful for uni-script
uni-direction text. The guessing behavior however is NOT the default of
hb_shape() and must be asked for explicitly. This is intended, because
the guess is not a suitable substitute to full-fledged bidi and script
segmentation. It's just a testing tool.
Behdad Esfahbod
Ryan Lortie
Bradley Grainger