* hb_ot_layout_feature_get_characters
* hb_ot_layout_feature_get_name_ids
However HarfBuzz currently doesn't expose an API for retrieving the actual
information associated with NameId from the `name` table and that should be
done separately.
If the second subtag of a BCP 47 tag is three letters long, it denotes
an extended language. The tag converter ignores the language subtag and
uses the extended language instead.
There are some grandfathered exceptions, which are handled earlier.
The new script, gen-tag-table.py, generates `ot_languages` automatically
from the [OpenType language system tag registry][ot] and the [IANA
Language Subtag Registry][bcp47] with some manual modifications. If an
OpenType tag maps to a BCP 47 macrolanguage, all the macrolanguage's
individual languages are mapped to the same OpenType tag, except for
individual languages with their own OpenType mappings. Deprecated
BCP 47 tags are canonicalized.
[ot]: https://docs.microsoft.com/en-us/typography/opentype/spec/languagetags
[bcp47]: https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
Some OpenType tags correspond to multiple ISO 639 codes. The mapping
from ISO 639 codes lists OpenType tags in priority order, such that more
specific or more likely tags appear first.
Some OpenType tags have no corresponding ISO 639 code in the registry so
their mappings use BCP 47 subtags besides the language. For example, any
BCP 47 tag with a fonipa variant subtag is mapped to 'IPPH', and 'IPPH'
is mapped back to und-fonipa.
Other OpenType tags have no corresponding ISO 639 code because it is not
clear what they are for. HarfBuzz just ignores these tags.
One such ignored tag is 'ZHP ' (Chinese Phonetic). It probably means
zh-Latn. However, it is used in Microsoft JhengHei and Microsoft YaHei
with the script tag 'hani', implying that it is not a romanization
scheme after all. It would be simple enough to add this mapping to
gen-tag-table.py once a definitive mapping is determined.
The manual modifications are mainly either obvious mappings that the
OpenType registry omits or mappings for compatibility with previous
versions of HarfBuzz. Some of the old mappings were discarded, though,
for homophonous language names. For example, OpenType maps 'KUI ' to
kxu; previous versions of HarfBuzz also mapped it to kvd, because kvd
and kxu both happen to be called "Kui".
gen-tag-table.py also generates a function to convert multi-subtag tags
like el-polyton and zh-HK to OpenType tags, replacing `ot_languages_zh`
and the hard-coded list of special cases in `hb_ot_tags_from_language`.
It also generates a function to convert OpenType tags to BCP 47,
replacing the hard-coded list of special cases in
`hb_ot_tag_to_language`.
The old hb-ot-tag.cc functions, `hb_ot_tags_from_script` and
`hb_ot_tag_from_language`, are now wrappers around a new function:
`hb_ot_tags`. It converts a script and a language to arrays of script
tags and language tags. This will make it easier to add new script tags
to scripts, like 'dev3'. It also allows for language fallback chains;
nothing produces more than one language yet though.
Where the old functions return the default tags 'DFLT' and 'dflt',
`hb_ot_tags` returns an empty array. The caller is responsible for
using the default tag in that case.
The new function also adds a new private use subtag syntax for script
overrides: "x-hbscabcd" requests a script tag of 'abcd'.
The old hb-ot-layout.cc functions,`hb_ot_layout_table_choose_script` and
`hb_ot_layout_script_find_language` are now wrappers around the new
functions `hb_ot_layout_table_select_script` and
`hb_ot_layout_script_select_language`. They are essentially the same as
the old ones plus a tag count parameter.
Closes#495.
Makes our FT-backed hb_font_t safe to use from multiple threads. Still,
the underlying FT_Face should NOT be used from other threads by client
or other libraries.
Maybe I add a lock()/unlock() public API ala PangoFT2 and cairo-ft.
Maybe not.
How come this one is not generated by clang everything bot?!
../../../test/api/test-multithread.c:37:26: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
static char *font_path = "fonts/Inconsolata-Regular.abc.ttf";
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../test/api/test-multithread.c:38:21: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
We might reintroduce it later, but for now remove, as it was unused.
Some things that should have been in this object (drop_hints, etc)
are already in hb_subset_input_t. So, for now, keep everything there.
* [subset] sanitize individual DeviceRecord's as part of hdmx sanitization.
* [subset] Fix out of bounds read with non-two byte align glyphs.
* [subset] Just use size_device_record >= DeviceRecord::min_size.
* [subset] Add TODO.
* [subset] Re-order checks in hdmx sanitize.
Before 1.7.5, we were setting -fno-exceptions etc on CXXFLAGS. In 1.7.6
we set it as CPPFLAGS. Try fixing. Also, I'm fairly sure it's safe to
set these unconditionally.
Fixes https://github.com/harfbuzz/harfbuzz/issues/880 (or so I hope)
Include stdbool.h in hb-setset-test.h instead of in the individual
sources, if it is found; otherwise use a simplistic fallback for it if
it is not found.
Also declare variables at the top of the block, to build on pre-C99
compiliers.
For the API tests, output the test programs at $(TOP_BUILDDIR) so that
the freshly-built DLLs will be available for the test programs. For
those that are run through the Python wrapper scripts, use
${PYTHON_EXECUTABLE} instead of plain 'python' in case the Python
interpreter is not in the PATH.
Ebrahim Byagowi
Behdad Esfahbod
David Corbett
Chun-wei Fan
lantw44
Garret Rieger
Jonathan Kew
rsheeter