1
0
mirror of https://github.com/opencv/opencv.git synced 2026-07-21 19:33:03 +04:00
Files
opencv/3rdparty/harfbuzz/src/OT/Layout/GPOS/MarkMarkPos.hh
T
Vadim Pisarevsky a3a4d4adac Merge pull request #29300 from vpisarev:add_harfbuzz
Added harfbuzz; use it instead of STB to render text #29300

Merge with https://github.com/opencv/opencv_extra/pull/1378.

This is the next big step to improve font rendering in OpenCV 5.x. See #18760, #26301. See also OpenCV 5.0 release notes, where it was pointed out that complex scripts are not rendered correctly, and HarfBuzz integration is needed to fix it. So, here it is — HarfBuzz integration:

* Removed tweaked STB engine. STB truetype rendering engine was included into OpenCV 5.0-pre/5.0 and it was extended to instantiate and render variable fonts, but the support was incomplete and immature.
* Instead, we now use [HarfBuzz](https://github.com/harfbuzz/harfbuzz) — famous font shaping library and now also font rendering library, used by many big companies and organizations.
* As a result, we now correctly render complex scripts, such as arabic or devanagari, correctly handle font ligatures (ff, fi, ft etc.)

<img width="1300" height="600" alt="text_test" src="https://github.com/user-attachments/assets/a7d2c754-0fcf-40f8-8104-578f3a14850b" />

* Potentially, we could also support color emoji, but that would be a next step.
* As with STB-based engine, glyphs are cached (the same glyph from the same font is not rendered twice), so the performance should be on par with the previous engine.
* When OpenCV is built with `-DWITH_HARFBUZZ=ON`, which is set by default, it tries to detect HarfBuzz in the system and use it. If it's not detected, OpenCV builds our own small subset of HarfBuzz.

The following table compares size of libopencv_imgproc.dylib.5.0.0 (Release mode) in different configurations:

| Configuration                          | libopencv_imgproc (stripped) | delta vs 5.0 |
|----------------------------------------|------------------------------|----------|
| imgproc without text rendering (`-DWITH_HARFBUZZ=OFF`)  | 4.27 MB  |  −2.35 MB |
| imgproc with stb-based engine (5.0)      | 6.62 MB      |  0.0 Mb |
| imgproc with HarfBuzz-based engine (this PR)     | 7.07 MB      |  +0.45 MB |

The biggest source of the size increase when OpenCV is built with text rendering support (STB- or Harfbuzz-based) is that imgproc in this case includes .ttf fonts (Rubik and 'Wen Quan Yi Micro Hei'), which are gzip-compressed, but still have noticeable size, especially 'Wen Quan Yi' (~2Mb). HarfBuzz itself, compared to STB engine, adds just 0.45Mb, or ~7% to imgproc size. On other platforms (Linux x64, Windows), where IPP or other acceleration libraries are linked into libopencv_imgproc, the harfbuzz footprint is even less noticeable.

### Pull Request Readiness Checklist

See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request

- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
      Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
2026-06-16 10:05:32 +03:00

43 lines
1011 B
C++

#ifndef OT_LAYOUT_GPOS_MARKMARKPOS_HH
#define OT_LAYOUT_GPOS_MARKMARKPOS_HH
#include "MarkMarkPosFormat1.hh"
namespace OT {
namespace Layout {
namespace GPOS_impl {
struct MarkMarkPos
{
protected:
union {
struct { HBUINT16 v; } format; /* Format identifier */
MarkMarkPosFormat1_2<SmallTypes> format1;
#ifndef HB_NO_BEYOND_64K
MarkMarkPosFormat1_2<MediumTypes> format2;
#endif
} u;
public:
template <typename context_t, typename ...Ts>
typename context_t::return_t dispatch (context_t *c, Ts&&... ds) const
{
if (unlikely (!c->may_dispatch (this, &u.format.v))) return c->no_dispatch_return_value ();
TRACE_DISPATCH (this, u.format.v);
switch (u.format.v) {
case 1: return_trace (c->dispatch (u.format1, std::forward<Ts> (ds)...));
#ifndef HB_NO_BEYOND_64K
case 2: return_trace (c->dispatch (u.format2, std::forward<Ts> (ds)...));
#endif
default:return_trace (c->default_return_value ());
}
}
};
}
}
}
#endif /* OT_LAYOUT_GPOS_MARKMARKPOS_HH */