14b018124c
...as seen with HarfBuzz used by LibreOffice, with `instdir/program/soffice --headless --convert-to pdf` of doc/abi6073-2.doc from the LibreOffice crash- testing corpus when run under UBSan, > hb-graphite2.cc:361:15: runtime error: -1024 is outside the range of representable values of type 'unsigned int' > #0 in _hb_graphite2_shape at workdir/UnpackedTarball/harfbuzz/src/hb-graphite2.cc:361:15 > #1 in _hb_shape_plan_execute_internal(hb_shape_plan_t*, hb_font_t*, hb_buffer_t*, hb_feature_t const*, unsigned int) at workdir/UnpackedTarball/harfbuzz/src/./hb-shaper-list.hh:38:1 > #2 in hb_shape_plan_execute at workdir/UnpackedTarball/harfbuzz/src/hb-shape-plan.cc:453:14 > #3 in hb_shape_full at workdir/UnpackedTarball/harfbuzz/src/hb-shape.cc:139:19 > #4 in GenericSalLayout::LayoutText(ImplLayoutArgs&, SalLayoutGlyphsImpl const*) at vcl/source/gdi/CommonSalLayout.cxx:495:23 > #5 in OutputDevice::getFallbackLayout(LogicalFontInstance*, int, ImplLayoutArgs&, SalLayoutGlyphs const*) const at vcl/source/outdev/font.cxx:1232:21 > #6 in OutputDevice::ImplGlyphFallbackLayout(std::unique_ptr<SalLayout, std::default_delete<SalLayout> >, ImplLayoutArgs&, SalLayoutGlyphs const*) const at vcl/source/outdev/font.cxx:1300:48 > #7 in OutputDevice::ImplLayout(rtl::OUString const&, int, int, Point const&, long, long const*, SalLayoutFlags, vcl::TextLayoutCache const*, SalLayoutGlyphs const*) const at vcl/source/outdev/text.cxx:1332:22 > #8 in lcl_CreateLayout(SwTextGlyphsKey const&, __gnu_debug::_Safe_iterator<std::_Rb_tree_iterator<std::pair<SwTextGlyphsKey const, SwTextGlyphsData> >, std::__debug::map<SwTextGlyphsKey, SwTextGlyphsData, std::less<SwTextGlyphsKey>, std::allocator<std::pair<SwTextGlyphsKey const, SwTextGlyphsData> > >, std::bidirectional_iterator_tag>) at sw/source/core/txtnode/fntcache.cxx:233:33 > #9 in SwFntObj::GetCachedSalLayoutGlyphs(SwTextGlyphsKey const&) at sw/source/core/txtnode/fntcache.cxx:257:12 > #10 in SwFont::GetTextBreak(SwDrawTextInfo const&, long) at sw/source/core/txtnode/fntcache.cxx:2551:58 > #11 in SwTextSizeInfo::GetTextBreak(long, o3tl::strong_int<int, Tag_TextFrameIndex>, unsigned short, vcl::TextLayoutCache const*) const at sw/source/core/text/inftxt.cxx:450:20 > #12 in SwTextGuess::Guess(SwTextPortion const&, SwTextFormatInfo&, unsigned short) at sw/source/core/text/guess.cxx:205:26 > #13 in SwTextPortion::Format_(SwTextFormatInfo&) at sw/source/core/text/portxt.cxx:305:32 > #14 in SwTextPortion::Format(SwTextFormatInfo&) at sw/source/core/text/portxt.cxx:456:12 > #15 in SwLineLayout::Format(SwTextFormatInfo&) at sw/source/core/text/porlay.cxx:260:31 (where in frame #4 GenericSalLayout::LayoutText, pHbBuffer->props.direction is HB_DIRECTION_RTL, in case that is relevant). It is unclear to me whether it is sufficient to only change hb_graphite2_cluster_t::advance from signed to unsigned int, as there are other unsigned int variables (like curradv in _hb_graphite2_shape) whose value depend on hb_graphite2_cluster_t::advance, and which thus might also become negative. But unlike the float -> unsigned int conversion that UBSan warned about here (where gr_slot_origin_X() and xscale are float), those are signed int -> unsigned int conversions that do not cause undefined behavior. At least, with this change, the above --convert-to pdf and a full `make check screenshot` succeeded for me under without further UBSan warnings. (For the version of HarfBuzz optionally built as part of the LibreOffice build, this has been addressed with <https://git.libreoffice.org/core/+/6e53e03f752c2f85283c4d47efaaf0683299783c%5E!/> "external/harfbuzz: hb_graphite2_cluster_t::advance can apparently be negative.") |
||
|---|---|---|
| .ci | ||
| .circleci | ||
| .github | ||
| docs | ||
| m4 | ||
| perf | ||
| src | ||
| subprojects | ||
| test | ||
| util | ||
| .clang-format | ||
| .codecov.yml | ||
| .editorconfig | ||
| AUTHORS | ||
| BUILD.md | ||
| CMakeLists.txt | ||
| CONFIG.md | ||
| COPYING | ||
| Makefile.am | ||
| NEWS | ||
| README | ||
| README.md | ||
| README.mingw.md | ||
| README.python.md | ||
| RELEASING.md | ||
| TESTING.md | ||
| THANKS | ||
| autogen.sh | ||
| configure.ac | ||
| git.mk | ||
| harfbuzz.doap | ||
| meson.build | ||
| meson_options.txt | ||
| mingw-configure.sh | ||
| replace-enum-strings.cmake | ||
README.md
HarfBuzz
HarfBuzz is a text shaping engine. It primarily supports OpenType, but also Apple Advanced Typography. HarfBuzz is used in Android, Chrome, ChromeOS, Firefox, GNOME, GTK+, KDE, LibreOffice, OpenJDK, PlayStation, Qt, XeTeX, and other places.
For bug reports, mailing list, and other information please visit:
For license information, see COPYING.
Documentation
For user manual as well as API documentation, check: https://harfbuzz.github.io
Download
For tarball releases of HarfBuzz, look here. At the same place you will also find Win32/Win64 binary bundles that include libharfbuzz DLL, hb-view.exe, hb-shape.exe, and all dependencies.
The canonical source tree is available on github.
The API that comes with hb.h will not change incompatibly. Other, peripheral,
headers are more likely to go through minor modifications, but again, we do our
best to never change API in an incompatible way. We will never break the ABI.
If you are not sure whether Pango or HarfBuzz is right for you, read Pango vs HarfBuzz.
Development
For build information, see BUILD.md.
For custom configurations, see CONFIG.md.
For testing and profiling, see TESTING.md.
To get a better idea of where HarfBuzz stands in the text rendering stack you may want to read State of Text Rendering, though, that document is many years old. Here are a few presentation slides about HarfBuzz at the Internationalization and Unicode Conference over the years:
- November 2014, Unicode, OpenType, and HarfBuzz: Closing the Circle,
- October 2012, HarfBuzz, The Free and Open Text Shaping Engine,
- October 2009, HarfBuzz: the Free and Open Shaping Engine.
Both development and user support discussion around HarfBuzz happens on the github.
To report bugs or submit patches please use github issues and pull-requests.
For a comparison of old vs new HarfBuzz memory consumption see this.
Name
HarfBuzz (حرفباز) is my Persian translation of “OpenType”, transliterated using the Latin script. It sports a second meaning, but that ain’t translatable.
Background: Originally there was this font format called TrueType. People and companies started calling their type engines all things ending in Type: FreeType, CoolType, ClearType, etc. And then came OpenType, which is the successor of TrueType. So, for my OpenType implementation, I decided to stick with the concept but use the Persian translation. Which is fitting given that Persian is written in the Arabic script, and OpenType is an extension of TrueType that adds support for complex script rendering, and HarfBuzz is an implementation of OpenType complex text shaping.
Packaging status of HarfBuzz
