As suggested by Ned, just ignoring it.
warning: 'CTGetCoreTextVersion' is deprecated: first deprecated in macOS 11.0 - Use
-[NSProcessInfo operatingSystemVersion] [-Wdeprecated-declarations]
Instead of trying to map OpenType features to AAT feature selectors
which only works for a small subset of OpenType features, use the
simpler kCTFontOpenTypeFeatureTag with OpenType feature tags directly.
With this change, features like cvXX can be enabled in coretext shaper,
while they were previously ignored due to missing mapping.
This seems to work even with AAT fonts that don’t have OpenType layout
tables, which suggests that CoreText is doing the mapping itself in this
case.
kCTFontOpenTypeFeatureTag seems to have been introduced in macOS 10.10
and iOS 8.0, though, so its use is conditional on version check for now.
Not sure how to check iOS version, so I left this out.
This makes it possible to include all .cc files into build, even if not
building CoreText, Uniscribe, etc.
This was mostly to help custom builders. But also means that we can
include all files in our own build system. Not sure if we should.
Definitely simplifies things, but slightly only.
Looks like static methods that do not get inlined end up exported.
We have a lot more. Need to protect all at some point. Wish there
was an easier way, like the visibility flag we pass that automatically
hides all inline methods.
Was exposed by check-symbols.sh when compiling on OS X 10.14 with:
$ make CPPFLAGS=-Oz CXXFLAGS=-flto=thin LDFLAGS=-lc++
coretext_aat was a temporary shaper to redirect shaping of AAT fonts
to CoreText and leaving the rest for HarfBuzz. As HarfBuzz now supports
AAT and Chrome now actually ships that on a stable version on macOS,
we no longer care about such use-case. If a client really wants 100%
metrics compatibility with CoreText better to use it directly or through
our API. Replicating the same behavior still is possible using
hb_shape_full, something we don't care or like to offer anymore.
Fixes https://github.com/harfbuzz/harfbuzz/issues/1478
TARGET_OS_OSX was introduced only in late OS versions
so always returns as "0" on older systems.
if !TARGET_OS_IPHONE can work, as it returns as !0 on older
systems where TARGET_OS_IPHONE is not defined, but is not
specific
if TARGET_OS_MAC && !(defined(TARGET_OS_IPHONE) && TARGET_OS_IPHONE)
is both specific and accurate on all systems.
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/
Behdad Esfahbod
Simon Cozens
Khaled Hosny
Khaled Hosny
René Meusel
Ebrahim Byagowi
Misty De Meo
Nathan Willis
Ken
Ken Cunningham
Tor Arne Vestbø