From clang -Weverything bot:
options.cc:39:3: warning: no previous extern declaration for non-static variable 'supported_font_funcs' [-Wmissing-variable-declarations]
Some clang versions define static_assert as a macro apparently, so we cannot
redefine it...
This reverts commit 94bfea0ce6.
This reverts commit 4e62627831.
This checks if the blob isn't empty and uses `hb_face_count`
to see if the font file passes the simple font file sanitization
so can detect if the input is actually a font and checks also
whether input font-index is out of range.
We were passing the font path directly to freetype so rendering
was broken when we are getting the font from stdin.
This fixes it by using FT_New_Memory_Face instead.
This fixes:
* build/util/hb-view /dev/stdin text < font.ttf
* build/util/hb-view - text < font.ttf
* cat font.ttf | build/util/hb-view - text
but doesn't work on
* cat font.ttf | build/util/hb-view /dev/stdin text
which I will try to fix separately.
New API:
HB_BUFFER_FLAG_REMOVE_DEFAULT_IGNORABLES
hb-shape / hb-view --remove-default-ignorables
One more text-rendering-tests test passing. Eleven failing.
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
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.
Behdad Esfahbod
Ebrahim Byagowi
Khaled Hosny
David Corbett
Rod Sheeter
Chun-wei Fan
Collin Fair