IssueNo:https://gitee.com/openharmony/third_party_harfbuzz/issues/I4X5GU
Feature or Bugfix: Feature
Binary Source:harfbuzz resources
Signed-off-by: Nlancer <haoshuo@huawei.com>

Description:harfbuzz版本降低到2.7.2
Sig:harfbuzz
Feature or Bugfix:Feature
Binary Source:No
Signed-off-by: Nlancer <haoshuo@huawei.com>

IssueNo: https://gitee.com/openharmony/third_party_harfbuzz/issues/I4H06M
Feature or Bugfix: Feature
Binary Source:No
Signed-off-by: Nlizhiqi <lizhiqi1@huawei.com>

The change to `round` wasn't intended

WHy do only some of the clang bots catch this I have no idea :(.

Part of https://github.com/harfbuzz/harfbuzz/issues/1553

Core Text doesn't actually have a concept of DPI internally, as it
doesn't rasterize anything by itself, it just generates vector paths
that get passed along to Core Graphics.

In practice this means Core Text operates in the classical macOS
logical DPI of 72, with one typographic point corresponding to one
point in the Core Graphics coordinate system, which for a normal
bitmap context then corresponds to one pixel -- or two pixels for
a "retina" context with a 2x scale transform.

Scaling the font point sizes given to HarfBuzz to an assumed DPI
of 96 is problematic with this in mind, as fonts with optical
features such as 'trak' tables for tracking, or color glyphs,
will then base the metrics off of the wrong point size compared
to what the client asked for.

This in turn causes mismatches between the metrics of the shaped
text and the actual rasterization, which doesn't include the 72
to 96 DPI scaling.

If a 96 DPI is needed, such as on the Web, the scaling should be
done outside of HarfBuzz, allowing the client to keep the DPI of
the shaping in sync with the rasterization.

The recommended way to do that is by scaling the font point size,
not by applying a transform to the target Core Graphics context,
to let Core Text choose the right optical features of the target
point size, as described in WWDC 2015 session 804:

  https://developer.apple.com/videos/play/wwdc2015/804/

Fixes https://github.com/harfbuzz/harfbuzz/issues/1303

Related https://github.com/harfbuzz/harfbuzz/issues/1301

Simplifies transient object creation.

Fixes https://github.com/harfbuzz/harfbuzz/issues/1301

Will come in through <T> if desired.

We were getting the first track record always.  Ie. this line:

       if (trackTable[i].get_track_value () == 0.f)
       {
-       trackTableEntry = &trackTable[0];
+       trackTableEntry = &trackTable[i];
        break;
       }

The rest is cleanup.

Fixes https://github.com/harfbuzz/harfbuzz/issues/1263 for the most part.

This concludes trak, as well as AAT shaping support!

Works beautifully!  Test coming.

Assumes graphemes only have one base glyph.

...like UnsizedArrayOf<>.

This fixes a class of crasher bugs, mostly with color and AAT tables.  We
cannot use nullable offsets to varsized data that does not declare min_size,
because it's nost safe to use our fixed-size null pool for types that have
their size external.  So, use non_null'able offsets for these.

A further enhancement would be to make use of min_size in Null<> itself.
Will try that after.

Sorry for the noise, downstream custom builders.  Please adjust.

In collaboration with Behdad

Splitted from #950 and #986 IIRC Chromium had a policy about this encouraging it,
not sure about automated way to detect and add them but for now lets have the needed
ones of them.