1. If there is any offset (x or y), print out both x and y offsets.
2. Always print out the advance in the major direction of the buffer.
Ie. even for zero-advance glyphs, print a "+0". This is more intuitive.
This reorders glyphs within the cluster to a nominal order. This should
have no visible effect on the output, but helps with testing, for
getting the same hb-shape output for visually-equal glyphs for each
cluster.
Computes all the glyphs that may be generated given a font and
set of Unicode characters.
The order of the Unicode characters is irrelevant.
Sample output:
behdad:util 0$ ./hb-ot-shape-closure Doulos\ SIL\ Regular.ttf f
f f_f
behdad:util 0$ ./hb-ot-shape-closure Doulos\ SIL\ Regular.ttf i
i
behdad:util 0$ ./hb-ot-shape-closure Doulos\ SIL\ Regular.ttf fi
f f_i f_f_i f_f i
behdad:util 0$ ./hb-ot-shape-closure DroidNaskh-Regular.ttf ب
uni0628 uni0628.init uni0628.medi uni0628.fina
behdad:util 0$ ./hb-ot-shape-closure DroidNaskh-Regular.ttf ا
uni0627 uni0627.fina
behdad:util 0$ ./hb-ot-shape-closure DroidNaskh-Regular.ttf با
uni0627 uni0627.fina uni0628 uni0628.init uni0628.medi uni0628.fina
behdad:util 0$ ./hb-ot-shape-closure DroidNaskh-Regular.ttf با --no-glyph-names
5 6 133 134 135 136
Most common usecase of hb-view is to test rendering of short words for
testing / inspection. Not having to type "--font-size 150" each time
isn't such a bad idea...
Also remove shaper_options argument to hb_shape_full(). That was
unused and for "future". Let it go.
More shaper API coming in preparation for plan/planned API.
This means the --features indices also refer to char position
instead of byte position now. Same for cluster values reported
by hb-shape.
Will add an option for byte indices later.
Behdad Esfahbod