Fixes this -fno-sanitize-recover=undefined check,
hb-ft.cc:869:27: runtime error: left shift of negative value -16384
#0 0x7ff8f47da843 in hb_ft_font_set_funcs /home/ebrahim/Desktop/harfbuzz/src/hb-ft.cc:869:27
#1 0x55f20a66c7d6 in font_options_t::get_font() const /home/ebrahim/Desktop/harfbuzz/util/options.cc:731:3
#2 0x55f20a668c1f in shape_consumer_t<output_buffer_t>::init(hb_buffer_t*, font_options_t const*) /home/ebrahim/Desktop/harfbuzz/util/./shape-consumer.hh:47:42
#3 0x55f20a668441 in main_font_text_t<shape_consumer_t<output_buffer_t>, 2147483647, 0>::main(int, char**) /home/ebrahim/Desktop/harfbuzz/util/./main-font-text.hh:75:14
#4 0x55f20a667f91 in main /home/ebrahim/Desktop/harfbuzz/util/hb-shape.cc:180:21
#5 0x7ff8f3df7ee2 in __libc_start_main (/usr/lib/libc.so.6+0x26ee2)
#6 0x55f20a6427ad in _start (/home/ebrahim/Desktop/harfbuzz/util/.libs/lt-hb-shape+0xd7ad)
This makes it possible to include all .cc files into build, even if not
building CoreText, Uniscribe, etc.
This was mostly to help custom builders. But also means that we can
include all files in our own build system. Not sure if we should.
Definitely simplifies things, but slightly only.
If compiler doesn't inline StructAtOffset, this was an error since we
only disable cast-align at call-site. So, move the cast out.
../src/hb-machinery.hh: In instantiation of 'const Type& StructAtOffset(const void*, unsigned int) [with Type = unsigned int]':
../src/hb-font.cc:146:85: required from here
../src/hb-machinery.hh:63:12: error: cast from 'const char*' to 'const unsigned int*' increases required alignment of target type [-Werror=cast-align]
{ return * reinterpret_cast<const Type*> ((const char *) P + offset); }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/hb-machinery.hh: In instantiation of 'Type& StructAtOffset(void*, unsigned int) [with Type = unsigned int]':
../src/hb-font.cc:147:79: required from here
../src/hb-machinery.hh:66:12: error: cast from 'char*' to 'unsigned int*' increases required alignment of target type [-Werror=cast-align]
{ return * reinterpret_cast<Type*> ((char *) P + offset); }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Use non-GRID-fitted values for metrics
See freetype/src/base/ftobjs.c:ft_recompute_scaled_metrics() and
the usage of GRID_FIT_METRICS inside.
Fixes https://github.com/behdad/harfbuzz/issues/1262
* Update hb-ft.cc
Makes our FT-backed hb_font_t safe to use from multiple threads. Still,
the underlying FT_Face should NOT be used from other threads by client
or other libraries.
Maybe I add a lock()/unlock() public API ala PangoFT2 and cairo-ft.
Maybe not.
Some more measurable speedup. The recent commits' speedups are as follows:
Testing with Roboto, ****when disabling kern and liga****:
Before:
FT --features=-kern,-liga
user↦ 0m0.521s
OT --features=-liga,-kern
user↦ 0m0.568s
After:
FT --features=-liga,-kern
user↦ 0m0.428s
OT --features=-liga,-kern
user↦ 0m0.470s
So, 17% speedup.
Note that FT callbacks are faster than OT these days since we added an advance
cache to FT. I don't think the difference is enough to justify adding a cache
to OT.
When not disabling kern, the thing is three times slower, so the speedups
are three times less impressive... Still, 5% not bad for a codebase that I
otherwise thought is optimized out.
Note that, because of this and other optimiztions in our main shaper,
disabling kern and liga, the OT shaper is now *faster* than the fallback
shaper. So, that's my recommendation to clients that need the absolute
fastest...
This reverts commit 5daf3bd449.
If other atexit callbacks try to destruct the objects we destruct
in atexit callbacks, bad things will happen.
I'll come up with some other way to catch premature destruction
of HB-owned objects.
Fixes https://github.com/behdad/harfbuzz/issues/618
When the font size or variations settings on underlying FT_Face change,
one can call hb_ft_font_changed() and continue using hb_font created using
hb_ft_font_create().
Fixes https://github.com/behdad/harfbuzz/issues/559
New API:
hb_ft_font_changed()
This one:
map->mask = (1 << (next_bit + bits_needed)) - (1 << next_bit);
before the fix, the shift was done as an int, causing overflow
if it ever got to 1 << 31. Sprinkle 'u's around.
Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=634805
Prior to this change the function `FT_Error FT_Done_Face(FT_Face *)` was
called through a pointer with the signature `void (void *)` resulting in
undefined behaviour.
New API:
- hb_font_get_nominal_glyph_func_t
- hb_font_get_variation_glyph_func_t
- hb_font_funcs_set_nominal_glyph_func()
- hb_font_funcs_set_variation_glyph_func()
- hb_font_get_nominal_glyph()
- hb_font_get_variation_glyph()
Deprecated API:
- hb_font_get_glyph_func_t
- hb_font_funcs_set_glyph_func()
Clients that implement their own font-funcs are encouraged to replace
their get_glyph() implementation with a get_nominal_glyph() and
get_variation_glyph() pair. The variation version can assume that
variation_selector argument is not zero.
The default FreeType load flags where changed from FT_LOAD_NO_HINTING
to FT_LOAD_DEFAULT in 2a9627c564.
This is crashing HarfBuzz-enabled FreeType as I suppose it causes
infinite recursion between HB and FT autohinter...
Revert the behavior change.
Fixes https://github.com/behdad/harfbuzz/issues/143
This changes the default load_flags of fonts created using
hb_ft_font_create() from NO_HINTING to DEFAULT. Hope that doesn't
break too much client code.
Code calling hb_ft_font_set_funcs() is unaffected.
For discussion see:
http://lists.freedesktop.org/archives/harfbuzz/2012-April/001905.html
Over time we have had added NO_HINTING all over the place in hb-ft. Finish it off.
Not setting ppem on hb-font disables get_contour_point() calls which is good anyway.
See comments in the commit.
When I originally wrote hb-ft, FreeType objects did not support reference
counting. As such, hb_ft_face_create() and hb_ft_font_create() had a
"destroy" callback and client was responsible for making sure FT_Face is
kept around as long as the hb-font/face are alive.
However, since this was not clearly documented, some clienets didn't
correctly did that. In particular, some clients assumed that it's safe
to destroy FT_Face and then hb_face_t. This, indeed, used to work, until
45fd9424c7, which make face destroy access
font tables.
Now, I fixed that issue in 395b35903e since
the access was not needed, but the problem remains that not all clients
handle this correctly. See:
https://bugs.freedesktop.org/show_bug.cgi?id=86300
Fortunately, FT_Reference_Face() was added to FreeType in 2010, and so we
can use it now. Originally I wanted to change hb_ft_face_create() and
hb_ft_font_create() to reference the face if destroy==NULL was passed in.
That would improve pretty much all clients, with little undesired effects.
Except that FreeType itself, when compiled with HarfBuzz support, calls
hb_ft_font_create() with destroy==NULL and saves the resulting hb-font on
the ft-face (why does it not free it immediately?). Making hb-face
reference ft-face causes a cycling reference there. At least, that's my
current understanding.
At any rate, a cleaner approach, even if it means all clients will need a
change, is to introduce brand new API. Which this commit does.
Some comments added to hb-ft.h, hoping to make future clients make better
choices.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=75299
Apparently they are not (advertised as?) safe on BSD systems.
We ignore the case of static libraries.
Whitelisted on glibc, Android, and MSVC / mingw.
https://bugs.freedesktop.org/show_bug.cgi?id=82246
Lohit-Punjabi has a upem of 769! We were losing one unit in our
code, and FreeType is losing another one... Test with U+0A06.
Has an advance of 854 in the font. We were producing 852.
Now we do 853, which is what FreeType is telling us.
n8willis
Behdad Esfahbod
Ebrahim Byagowi
Khaled Hosny
Nathan Willis
HinTak
Emil A Eklund
prrace
Bruce Mitchener
Olivier Blin
Sascha Brawer
Birunthan Mohanathas
Simon Cozens
Chris Peterson