Found via `codespell -q 3 -S ./perf/texts -L actualy,als,ba,beng,clen,crasher,dependant,eachother,fo,gir,inout,ist,nd,ned,ot,pres,ro,statics,te,teh,timne`
GTK-Doc does not like the empty lines here, and interprets everything
after the first empty line as the description of the enum itself not a
specific member and the generated text makes no sense.
Removing the empty lines makes the text harder to read (both in source
and HTML), but at least it is correctly organized.
Instead of using gid=0 when a character is not found in the font,
client can now set a custom value. This is useful for shaper-driven
font fallback and to differentiate that from .notdef glyph.
Fixes https://github.com/harfbuzz/harfbuzz/issues/1360
HB_GLYPH_FLAG_UNSAFE_TO_BREAK means that the glyph with this flag is somehow affected by the previous logical glyph (the previous index in the buffer if ltr and the next index if the buffer is rtl). If these two glyphs are separated by a break (line or otherwise) then the underlying text should be re-shaped on both sides up to corresponding position in the text of some glyph not marked with this flag.
New API:
HB_BUFFER_FLAG_REMOVE_DEFAULT_IGNORABLES
hb-shape / hb-view --remove-default-ignorables
One more text-rendering-tests test passing. Eleven failing.
* hb-buffer.h: Mark hb_buffer_diff() for export
This will fix the tools builds on Visual Studio, as the symbol is used
by the tools.
* build: Adapt NMake Makefiles for GLib 2.53.4 or later
glib-mkenums was ported from a PERL script to a Python script, so we
need to update how we generate the enum sources for HarfBuzz-GObject in
the NMake builds. Let this be known in the build documentation for MSVC
builds.
One of the problems with the underlying cmd.exe that the NMake Makefiles
run on is that shebang lines are not recognized, so we need to to test
run the script with Python and see whether it succeeded by outputing a
source file that is larger than 0 in file size (since running the PERL
version of the script will clearly fail and cause an empty file to be
created).
If it succeeds, we then run a small Python utility script that makes the
necessary string replacements, and we are done. If that fails, then we
run the glib-mkenums script with PERL, and do the replacements with the
PERL one-liners as we did before.
We need to make replace.py use latin-1 encoding when using Python 3.x to
cope with the copyright sign that is in the generated enum sources.
Behdad Esfahbod
luz paz
Khaled Hosny
Nathan Willis
Simon Cozens
Ebrahim Byagowi
Khaled Hosny
Eric Muller
bungeman
Bruce Mitchener
fanc999