Before, that was printed using --debug (and in both hb-shape and hb-view).
Changed it, now hb-shape has a new command-line argument called --show-messages.
When invoked, it also respects other output formatting options. The messages
are better formatted and printed to te same place that hb-shape output is
directed to. Previously they were written to stderr.
Fixes https://github.com/behdad/harfbuzz/issues/506
This moves all the source listings in src/Makefile.am,
src/hb-ucdn/Makefile.am and util/Makefile.am into separate Makefile
snippets, so that they may be shared between different Makefile-based
build systems, such as NMake for Visual Studio.
Currently just announces lookup applications. Message-API *will* change.
hb-shape / hb-view are updated to print-out messages to stder if --debug
is specified.
Pre-2013 MSVC does not have scalbn() and scalbnf(), which are used in the
utility programs. Add fallback implementations for these, which can be
used when necessary.
Use the fallback implementation for lround() only on pre-2013 Visual
Studio, and ensure we are clear about the types of the parameters for
lround() and scalbnf(), since Visual Studio can be quite picky on
ambiguous parameter types. Also, use g_ascii_strcasecmp() rather than
strcasecmp() as we are already using GLib for this code and we are
assured that g_ascii_strcasemp() is available.
For scalbnf() on pre-2013 Visaul Studio, a fallback implementation is
needed, but use another forced-included header for those compilers, which
will be added later.
Also use (char)27 on Visual Studio builds as '\e' is not a recognized
escape sequence, which will do the same thing.
This has the effect that the font data will end up in a memory
section malloc()ed exactly to its size. This gives us better
valgrind detection of out-of-bounds access.
Previously, the font data was placed in a mmap()ed section or
GString-allocated area, which didn't have proper protections
at the end when running under valgrind.
Before, if one called hb_shape() without setting script, language, and
direction on the buffer, hb_shape() was calling
hb_buffer_guess_segment_properties() on the user's behalf to guess
these.
This is very dangerous, since any serious user of HarfBuzz must set
these properly (specially important is direction). So now, we don't
guess properties by default. People not setting direction will get
an abort() now. If the old behavior is desired (fragile, good for
simple testing only), users can call
hb_buffer_guess_segment_properties() on the buffer just before calling
hb_shape().
If you say:
hb-shape font.ttf text --output-file out.txt
This was previously failing:
Unknown output format `txt'; supported formats are: TEXT / JSON
Now we simply fallback to TEXT if no explicit format was requested.
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
Behdad Esfahbod
Philip Withnall
Chun-wei Fan
Collin Fair