This adds a set of NMake Makefiles that can be used to build HarfBuzz, from
the standard basic build building the minimal HarfBuzz DLL (consisting
of OpenType, fallback and Uniscribe support only), to a full fledged build
consisting of GLib and FreeType support, as well as building the utilities,
the test programs in src/ and test/api, and HarfBuzz-ICU and
HarfBuzz-GObject, and up to building the introspection files. This means a
flexible build mechanism is supported here, so anything that is supported
for a Windows build (code-wise), should all be supported by this build
system.
As in an earlier commit, the source listings are shared with the autotools
builds with the various Makefile.sources in src/, src/hb-ucdn and util/, and
this set of NMake Makefiles will transform these lists into the form they
want.
In the current form, all the test programs in test/api pass, and this has
been checked successfully with 'make -j8 distcheck'.
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
As in building for Android / iPhone. Only set it if
struct{char} alignment is not 1.
NOT tested on an actual Arm architecture. Guess we'll know
when this makes it to people's build bots.
They've been disabled for a while and no one cared. We're past
the point to need them for testing, and if we ever need to
resurrect them again, well, they're in git graveyard somewhere.
Initial setup of gtk-doc. Straight forward setup following the gtk-doc
instructions. Ignore some troublesome types in src/hb-gobject.h. To
build use "./autogen.sh --enable-gtk-doc" then "make". Docs are in
harfbuzz/docs/reference/html/index.html.
When installing per-process fonts using AddFontMemResourceEx(),
if a font with the same family name is already installed, sometimes
that one gets used. Which is problematic for us. As such, we
now mangle the font to install a new 'name' table with a unique
name, which we then use to choose the font.
Patch from Jonathan Kew.
Bug 65246 - Fix build without graphite2
If we don't provide ACTION-IF-NOT-FOUND, configure aborts if it can't
find the libraries. We handle that ourselves so we don't want the
macro to abort.
We only want UCDN if we don't have any other Unicode provider.
I'm going to remove ICU from the list of default Unicode providers
as part of moving hb-icu into its own library. As such, the only
providers will be UCDN and glib.
This is not ideal as we don't like -L/usr/lib in our linker line.
But this is only relevant to environments that don't have pkgconfig
files for ICU...
https://github.com/behdad/harfbuzz/pull/2
Ubuntu doesn't (or didn't until recently?) ship icu pkg-config
files. That's quite unfortunate. Work around it.
Bug 57608 - ICU Detection fallback for non-pkgconfig systems
Apparently even that doesn't make check-internal-symbols.sh happy with
mingw32. Going to disable that for DLLs again, but hopefully the
export-file is doing *something*.
Does not attempt to handle clusters in a Uniscribe- or HarfBuzz-compatible way;
just returns the original string indexes that CT maintains. These may even be
out-of-order in the case of reordrant glyphs.
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
And this, concludes the HarfBuzz Massala Hackfest.
I like to specially thank Jonathan Kew for doing all the decription and
letting me get commit points.
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.
