Bug#918774: liblasi0: response to missing system glyphs no longer works correctly
Package: liblasi0
Version: 1.1.0-2
Severity: important
Dear Maintainer,
Since one of my recent Debian Buster upgrades I have been getting the
following run-time errors with libLASi when a missing system glyph is
encountered:
terminate called after throwing an instance of 'std::runtime_error'
what(): Error returned from FT_Load_Glyph
Aborted
You definitely don't want libLASi to throw errors and abort when
encountering missing system glyphs because that situation is fairly
common. Therefore, I have rated the severity level of this bug as
important.
The relevant libLASi code that attempts to do something responsible
when encountering missing system glyphs is the following code in
libLASi-1.1.0 (and also libLASi-1.1.2).
FT_Error error = FT_Load_Glyph(face,glyph_index,FT_LOAD_NO_BITMAP);
if(error){
//
//DEBUG:
//
//std::cerr << "PANGO is returning a glyph index of " << std::hex << glyph_index << std::endl;
//std::cerr << "but PANGO_GLYPH_UNKNOWN_FLAG is supposed to be: " << 0x10000000 << std::endl;
//std::cerr << "and PANGO_GLYPH_EMPTY is supposed to be: " << 0x0FFFFFFF << std::endl;
//
// Substitute something that works: All fonts are supposed
// to handle glyph_index 0 as the default replacement glyph:
//
evalReturnCode(FT_Load_Glyph(face,0,FT_LOAD_NO_BITMAP),"FT_Load_Glyph");
}else{
evalReturnCode(FT_Load_Glyph(face, glyph_index,FT_LOAD_NO_BITMAP), "FT_Load_Glyph");
}
where evalReturnCode is the following inline routine (in both 1.1.0 and 1.1.2):
/** Converts a freetype return code into an exception.
*/
inline void evalReturnCode(const int errCode, const char* funcName) throw (std::runtime_error) {
if (errCode)
throw std::runtime_error(std::string("Error returned from ") + funcName);
}
So the obvious purpose of the above code is whenever there is some
issue with FT_Load_Glyph for a give glyph_index it tries again with
glyph_index = 0 which according to the above notes should always "just work" without
throwing an error.
In any case this technique for avoiding throwing errors on missing glyphs worked
perfectly over the years, and I can see no
reason why it has suddenly started throwing errors now. But since my
recent Debian Buster upgrades did not involve libLASi, this bug should
likely be reported against one of the many dependencies of libLASi,
but I don't know which one so I have started the process by reporting
the bug here.
I haven't tried this myself yet, but I am virtually positive you can
easily verify this issue by building and running
libLASi-1.1.0/examples/MissingGlyphExample.cpp.
Instead of performing that direct test of libLASi, I have been
indirectly testing libLASi over many years via regular PLplot testing
since PLplot includes the psttf device which links to libLASi. The
examples we test do include missing glyphs, and my recent PLplot tests
have recently started erroring out with the above abort for our psttf
device driver which is the motivation for this bug report.
FYI, I am far from expert with libLASi and C++, but I do have some
familiarity with the libLASi code because I have helped some upstream
with its build system and bug releases over the years (because of my
PLplot interest).
So if there are some further tests you would like me to try because
you are having trouble verifying this bug with
MissingGlyphExample.cpp, please let me know.
Alan
-- System Information:
Debian Release: buster/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.10-custom (SMP w/16 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages liblasi0 depends on:
ii libc6 2.28-2
ii libfontconfig1 2.13.1-2
ii libfreetype6 2.9.1-3
ii libgcc1 1:8.2.0-13
ii libglib2.0-0 2.58.2-3
ii libpango-1.0-0 1.42.4-6
ii libpangoft2-1.0-0 1.42.4-6
ii libstdc++6 8.2.0-13
liblasi0 recommends no packages.
liblasi0 suggests no packages.
-- no debconf information
Reply to: