It is desirable to be able to build against older versions of glib.
fd7a245 changed the configure check to require glib > 2.38 for
G_TEST_DIST. Before that, version 2.16 was required, but in fact,
since aafe395, G_PASTE is being used, which was introduced in 2.19.1.
And since 0ef179e2, hb-glib uses GBytes, which were introduced in
2.31.10.
2.19.1 is rather old, but 2.38 is rather new. For Firefox, building
against 2.22 is still supported, although we could probably get away
with bumping that to 2.28. Either way, GBytes is not available.
Arguably, if you build against a glib that doesn't support GBytes,
you're not going to use the hb_glib_blob_create function, so we hide
the function when building against such a glib.
As for G_TEST_DIST, when building against versions of glib that don't
support it, we can fallback to the previous behavior, which, AIUI, was
just making the test not work when building in a separate directory.
The default tar-v7 is not good enough for us (99 char filename
limit), so I have had bumped to tar-pax. We got one complaint
that someone's tar couldn't handle tar-pax. Set to tar-ustar
which is ~13 years earlier than tar-pax and is good enough for us.
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.
hb_shape() now accepts a shaper_options and a shaper_list argument.
Both can be set to NULL to emulate previous API. And in most situations
they are expected to be set to NULL.
hb_shape() also returns a boolean for now. If shaper_list is NULL, the
return value can be ignored.
shaper_options is ignored for now, but otherwise it should be a
NULL-terminated list of strings.
shaper_list is a NULL-terminated list of strings. Currently recognized
strings are "ot" for native OpenType Layout implementation, "uniscribe"
for the Uniscribe backend, and "fallback" for the non-complex backend
(that will be implemented shortly). The fallback backend never fails.
The env var HB_SHAPER_LIST is also parsed and honored. It's a
colon-separated list of shaper names. The fallback shaper is invoked if
none of the env-listed shapers succeed.
New API hb_buffer_guess_properties() added.
Mike Hommey
Behdad Esfahbod
Phil Krylov
Khaled Hosny
Kal Conley
Chun-wei Fan
Konstantin Ritt
Dominik Röttsches
Anthony Carrico
John Ralls
Jonathan Kew