harfbuzz/harfbuzz@99f4668 fixes a bug in the repacker that can result in incorrect packing via hb_repack in some rare cases.

Is there a reason to require the user to set it explicitly afterwards? Would shave another two lines off the example.

import uharfbuzz as hb
print(hb.BufferClusterLevel.MONOTONE_GRAPHEMES == 1)

This prints False, but shouldn't it be True?

It would be good to get out a new release that contains the harfbuzz change harfbuzz/harfbuzz@9c25189

This fixes an issue in fonttool's use of the repacker: fonttools/fonttools#2691

★ 2.7k  3.6k

  Good first issues

  Fishing Tooltip does not update on level-up

  Clarify Plugin Hub risk label

  GitHub topic recommendation

  # covid19

  

  

upstream Harfbuzz library will be switching to use meson as its build system, which means they may drop support for CMake some time in the future.
For uharfbuzz bindings, we use scikit-build as our python build system, which in turn uses CMake to orchestrate the build.
We should see if we can use Meson to build the cython extension module instead of CMake.

There's a package called mesonpep517 that helps with creating python dists and wheels with meson (see mesonpep517 docs)

On mesonbuild repo there's an example of a cython module built with meson:
https://github.com/mesonbuild/meson/tree/master/test%20cases/python3/3%20cython

I noticed this while setting up Github Actions #73, since cibuildwheel attempts to build a wheel for pypy by default.
These are the failues:
https://github.com/harfbuzz/uharfbuzz/runs/1919782201?check_suite_focus=true#step:6:1008
https://ci.appveyor.com/project/fonttools/uharfbuzz/builds/37821221

>>> import uharfbuzz as hb
>>> buffer = hb.Buffer()
>>> buffer.script
''
>>> buffer.language
zsh: segmentation fault  python3

This works when reading language after setting a value to it.

bf4105e updated to harfbuzz 5.3.1. Can we get a new release that includes this commit?

Trying to update Arch Linux packaging, and the source ... isn't there yet. The release and a bunch of prebuilt wheels are, but not the source ZIP that was previously available on releases. It's possible to switch to Github sources, but the use of setuptools-scm makes that complicated and I would have to setup a patch to remove it and fill in the missing release info. The generated source dist is much easier to work with.

It appears that the info.cluster index is utf-8-based, not unicode character index, as if using hb-shape --utf8-clusters. Is this intentional? Intuitively I would have assumed info.cluster would be a unicode char index.

https://pypi.org/project/uharfbuzz/0.16.0/#files

Using the newly published 0.13.1 source distribution from PyPi:

$ python setup.py build
running build
running build_py
copying src/uharfbuzz/_version.py -> build/lib.linux-x86_64-3.8/uharfbuzz
running build_ext
building 'uharfbuzz._harfbuzz' extension
gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -march=x86-64 -mtune=generic -O3 -pipe -fno-plt -fno-semantic-interposition -march=x86-64 -mtune=generic -O3 -pipe -fno-plt -march=x86-64 -mtune=generic -O3 -pipe -fno-plt -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -D_FORTIFY_SOURCE=2 -fPIC -DHB_NO_MT=1 -DHB_EXPERIMENTAL_API=1 -Iharfbuzz/src -I/usr/include/python3.8 -c src/uharfbuzz/_harfbuzz.cpp -o build/temp.linux-x86_64-3.8/src/uharfbuzz/_harfbuzz.o -std=c++11
src/uharfbuzz/_harfbuzz.cpp:654:10: fatal error: hb.h: No such file or directory
  654 | #include "hb.h"
      |          ^~~~~~
compilation terminated.
error: command 'gcc' failed with exit status 1

The extracted package doesn't seem to have the referenced hb.h header file at all. In fact it doesn't include any of the sources needed to build Harfbuzz.

I'm sorry for asking this here, can you recommend me a book or reference or article or any resource about Arabic fonts unicode reshaping that i can learn from it how the Arabic text are reshaped so i can implement it in code ?

Just been looking through uharfbuzz and the fonts and faces section of the Harfbuzz docs which suggests setting hb_font_set_ppem and hb_font_set_ptem.

I don't see any way of accessing these attributes but wondered if I was missing something obvious.

It looks like a trivial fix, if the scale properties are anything to go by, but wanted to ask before making a pull request.

I'm trying to figure out hot to use set_glyph_h_advance_func(), and I'm guessing the intended pattern would be something like

import uharfbuzz as hb
import sys


with open(sys.argv[1], 'rb') as fontfile:
    fontdata = fontfile.read()

text = sys.argv[2]

face = hb.Face.create(fontdata)
font = hb.Font.create(face)
upem = face.upem

font.scale = (upem, upem)
hb.ot_font_set_funcs(font)

def myfunc(font, gid, user):
    return 500
funcs = hb.FontFuncs()
funcs.set_glyph_h_advance_func(myfunc, None)
font.funcs = funcs

buf = hb.Buffer.create()

buf.add_str(text)
buf.guess_segment_properties()

features = {"kern": True, "liga": True}
hb.shape(font, buf, features)

infos = buf.glyph_infos
positions = buf.glyph_positions

for info, pos in zip(infos, positions):
    gid = info.codepoint
    cluster = info.cluster
    x_advance = pos.x_advance
    x_offset = pos.x_offset
    y_offset = pos.y_offset
    print(f"gid{gid}={cluster}@{x_advance},{x_offset}+{y_offset}")

But this results in a segmentation fault at funcs.set_glyph_h_advance_func(myfunc, None)

I'm observing a difference of one unit for an advance width in a variable font between hb-shape and uharfbuzz: at one location the unrounded advance would be exactly 495.5: with hb-shape this gets rounded up to 496 (which is correct) and with uharfbuzz it gets rounded down to 495 (which isn't).

I have constructed the font so that the normalized axis value is perfectly representable as a 2dot14 fixed.

The attached zip file contains a test font and a test script. The font contains one glyph ("A") and one axis ("TEST").

The TEST axis goes from 482 to 518, with the default right in the middle at 500.
The advance width of glyph A goes from 491 to 509, with the default at 500. So the axis value moves twice as fast as the advance width.

At TEST=491 (in between min and default) the problem occurs.

The output of the test script:

482 - 491 491 491.0 True
491 - 495 496 495.5 False
500 - 500 500 500.0 True
509 - 505 505 504.5 True
518 - 509 509 509.0 True

(Axis value, uharfbuzz advance, hb-shape advance, unrounded advance, equal)

The hb-shape version I tested with was 2.6.2, uharfbuzz is at HB 2.6.5.

round_test.zip

python code/lesson1/boxes.py ./pride-and-prejudice.txt lesson1.svg
Traceback (most recent call last):
  File "code/lesson1/boxes.py", line 7, in <module>
    from fonts import adjust_widths_by_letter
  File "/Users/ralsina/code/boxes-book/src/part2/code/lesson1/fonts.py", line 1, in <module>
    import uharfbuzz as hb
  File "/Users/ralsina/.virtualenvs/boxes-book/lib/python3.7/site-packages/uharfbuzz/__init__.py", line 1, in <module>
    from ._harfbuzz import *
ImportError: dlopen(/Users/ralsina/.virtualenvs/boxes-book/lib/python3.7/site-packages/uharfbuzz/_harfbuzz.cpython-37m-darwin.so, 2): Symbol not found: _kCTFontAttributeName
  Referenced from: /Users/ralsina/.virtualenvs/boxes-book/lib/python3.7/site-packages/uharfbuzz/_harfbuzz.cpython-37m-darwin.so
  Expected in: flat namespace
 in /Users/ralsina/.virtualenvs/boxes-book/lib/python3.7/site-packages/uharfbuzz/_harfbuzz.cpython-37m-darwin.so

This happens both with the wheel and building from source.
I do have libharfbuzz installed via brew, and it works with another binding.

uname -a                                                                          
Darwin C02WK0ZFHTD8 17.4.0 Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64 x86_64

lrwxr-xr-x  1 ralsina  admin  56 Jul 24 14:13 /usr/local/lib/libharfbuzz-gobject.0.dylib -> ../Cellar/harfbuzz/1.8.4/lib/libharfbuzz-gobject.0.dylib
lrwxr-xr-x  1 ralsina  admin  50 Jul 24 14:13 /usr/local/lib/libharfbuzz-gobject.a -> ../Cellar/harfbuzz/1.8.4/lib/libharfbuzz-gobject.a
lrwxr-xr-x  1 ralsina  admin  54 Jul 24 14:13 /usr/local/lib/libharfbuzz-gobject.dylib -> ../Cellar/harfbuzz/1.8.4/lib/libharfbuzz-gobject.dylib
lrwxr-xr-x  1 ralsina  admin  52 Jul 24 14:13 /usr/local/lib/libharfbuzz-icu.0.dylib -> ../Cellar/harfbuzz/1.8.4/lib/libharfbuzz-icu.0.dylib
lrwxr-xr-x  1 ralsina  admin  46 Jul 24 14:13 /usr/local/lib/libharfbuzz-icu.a -> ../Cellar/harfbuzz/1.8.4/lib/libharfbuzz-icu.a
lrwxr-xr-x  1 ralsina  admin  50 Jul 24 14:13 /usr/local/lib/libharfbuzz-icu.dylib -> ../Cellar/harfbuzz/1.8.4/lib/libharfbuzz-icu.dylib
lrwxr-xr-x  1 ralsina  admin  55 Jul 24 14:13 /usr/local/lib/libharfbuzz-subset.0.dylib -> ../Cellar/harfbuzz/1.8.4/lib/libharfbuzz-subset.0.dylib
lrwxr-xr-x  1 ralsina  admin  49 Jul 24 14:13 /usr/local/lib/libharfbuzz-subset.a -> ../Cellar/harfbuzz/1.8.4/lib/libharfbuzz-subset.a
lrwxr-xr-x  1 ralsina  admin  53 Jul 24 14:13 /usr/local/lib/libharfbuzz-subset.dylib -> ../Cellar/harfbuzz/1.8.4/lib/libharfbuzz-subset.dylib
lrwxr-xr-x  1 ralsina  admin  48 Jul 24 14:13 /usr/local/lib/libharfbuzz.0.dylib -> ../Cellar/harfbuzz/1.8.4/lib/libharfbuzz.0.dylib
lrwxr-xr-x  1 ralsina  admin  42 Jul 24 14:13 /usr/local/lib/libharfbuzz.a -> ../Cellar/harfbuzz/1.8.4/lib/libharfbuzz.a
lrwxr-xr-x  1 ralsina  admin  46 Jul 24 14:13 /usr/local/lib/libharfbuzz.dylib -> ../Cellar/harfbuzz/1.8.4/lib/libharfbuzz.dylib

I've been writing a more Pythonic layer on top of uharfbuzz. I would gladly contribute it (I can see it as a submodule in uharfbuzz), if people here agree this is useful.

Just posting this here to test the waters, I can gladly make a PR:

hbShape.py.zip

Perhaps as something like uharfbuzz.shape.Shaper.

We currently don't support setting or unsetting of features for only part of the input buffer.

I don't yet understand the underlying HB calls needed to achieve this, and I also don't yet see what such an API could look like from the Python side. Could it be an operation on the buffer?

https://twitter.com/simoncozens/status/1275806808104370176

We currently always return 1:

uharfbuzz currently suggests reading fonts like,

with open(sys.argv[1], 'rb') as fontfile:
    fontdata = fontfile.read()

text = sys.argv[2]

face = hb.Face(fontdata)
font = hb.Font(face)
upem = face.upem

but that's sub-optimal, one can enable HAVE_MMAP https://github.com/harfbuzz/harfbuzz/blob/master/src/hb-blob.cc#L478-L485 for non-Windows platforms (Windows build config is already fine) and use hb_blob_create_from_file instead so it won't read whole font at once, I wonder however is uharfbuzz used in places that lots of fonts are loaded (I guess?) thus worth the font loading optimization? This needs tweaking the python API also of course.

we should replace Travis CI with Github Actions, at least for the mac and linux builds, the windows appveyor can stay for now.

cibuildwheel docs say that it works with github actions.

I don't have time to work on this, but i'm happy to review PRs

Using a different binding I had a line like this:

face.set_char_size(size=1, resolution=64)

I can't find the equivalent in uharfbuzz (or in harfbuzz for that matter ;-)

Any ideas?

I'm trying to use uharfbuzz with a custom advance width function.

The first thing I noticed that if you use set_glyph_h_advance_func() you also have to use set_nominal_glyph_func(), which is a little inconvenient and unexpected, but not too hard to work around. So I also made a custom "nominal_glyph_func" function, that looks up a code point in the cmap as given by fontTools.

This works mostly alright.

The test font (included in the zip) contains a couple of precombined diacritics, and a mark feature that takes care of A + macroncmb and E + macroncmb. Without the custom functions, both precomposed and base + combining mark work as text input. But as soon as I use the custom functions neither work anymore. See the showProblem switch in the test script.

It may very well that I'm not using the API correctly, but if so, I don't have a clue what I'm doing wrong.

testdata+script.zip

I've been experimenting with:
https://github.com/tarruda/python-autopxd

besides a few py3 glitches it seems to work quite well.

I only had to add a from libc.stdint cimport * for the fixed-with integer types and a few "opaque" ctypedef struct definitions.
I think we could fix these, and then we would be able to simply run this autopxd script to autogenerate the pxd cython declarations from the harfbuzz hb.h (and hb-ot.h) headers.

The following snippet will not raise an error:

import uharfbuzz as hb
hb.Blob.from_file_path("asdasgdjh")

It should probably use https://harfbuzz.github.io/harfbuzz-hb-blob.html#hb-blob-create-from-file-or-fail under the hood?

Tried it in python 3.7 gives this error

$ pip3 install uharfbuzz                                                                           
Collecting uharfbuzz
  Downloading https://files.pythonhosted.org/packages/e6/62/e74edc052bf27cf471ef767b4b9a8f94e3b7efa27cae6951e288a438930a/uharfbuzz-0.1.3.zip
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/private/var/folders/xb/nbwgxr110kbc1bphq6mqlmxc0000gq/T/pip-install-mwqnkf_p/uharfbuzz/setup.py", line 41, in <module>
        from skbuild import setup
    ModuleNotFoundError: No module named 'skbuild'```

It would be nice to have bindings for the subset library, after its API is stabilized (i.e. after HarfBuzz 3.0.0).

Now we have draw_glyph_with_pen this library is no longer a plain wrapper around the Harfbuzz API. I suggest we move uharfbuzz unique functions to a separate Python file where they can be documented. My Cython-fu is not good enough to know how to do this.

uharfbuzz has only support to add glyphs to a buffer as text or as a list of unicodes: add_codepoints, add_str, add_utf8 but not as glyph indexes this would be super handy...

I dont know if harfbuzz its self has support for this

see typemytype/featurePreviewRoboFontExtension#8

Good first issues

Document edited status

Keep filename label (and progress spinner) visible

Since we did it for CoreText on macOS, would be good to also do it for the native shaper on Windows.
I'm not sure how difficult that would be, any help appreciated.

BTW, I recently discovered that @paullinnerud at Microsoft have been working on a uharfbuzz-like cython module that wraps DirectWrite API with an interface almost identical to uharfbuzz, check it out at https://github.com/microsoft/DWriteShapePy

in addition to the x86_64 wheels that we already build, cibuildwheel project can now also build native wheels for the Apple Silicon platform, see https://cibuildwheel.readthedocs.io/en/stable/faq/#apple-silicon on how to enable those

I'm not sure if the issue is with this project or upstream, but trying to update Arch packaging for this and building in a clean chroot, I get:

gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -march=x86-64 -mtune=generic -O3 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -flto=auto -ffat-lto-objects -march=x86-64 -mtune=generic -O3 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -flto=auto -march=x86-64 -mtune=generic -O3 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -flto=auto -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fPIC -DHB_NO_MT=1 -DHB_EXPERIMENTAL_API=1 -DHAVE_MMAP=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_MMAN_H=1 -Iharfbuzz/src -I/usr/include/python3.10 -c harfbuzz/src/harfbuzz.cc -o build/temp.linux-x86_64-3.10/harfbuzz/src/harfbuzz.o -std=c++11
In file included from harfbuzz/src/hb-ot-face.cc:42,
                 from harfbuzz/src/harfbuzz.cc:17:
harfbuzz/src/hb-ot-layout-gsub-table.hh:32:10: fatal error: OT/Layout/GSUB/GSUB.hh: No such file or directory
   32 | #include "OT/Layout/GSUB/GSUB.hh"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~

Sure enough there is no GSUB.hh in the sources as distributed on PyPi, but it is referenced in the sources in harfbuzz/src/hb-ot-layout-gsub-table.hh.

More of a question, really, sorry about the medium :-)

In the example, you are loading the font from a file:

with open(sys.argv[1], 'rb') as fontfile:
    fontdata = fontfile.read()

text = sys.argv[2]

face = hb.Face.create(fontdata)
font = hb.Font.create(face)
upem = face.upem

How can I find the font in the system instead? Basically I want the equivalent of this freetype-based code:

    font_lib = ft.get_default_lib()
    face = font_lib.find_face("Arial")
    face.set_char_size(size=1, resolution=64)
    font = hb.Font.ft_create(face)

Currently the binding to hb_font_get_extents_for_direction() does not exist.

I think it's useful to implement hb-view ish utilities in Python. What are your thoughts?

I just can’t figure out how to build uharfbuzz on Mojave. I have installed XCode and the XCode command line tools.

[...]
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- broken
  CMake Error at /private/var/folders/dp/c9fjc9m107v4pqjyprys509h0000gn/T/pip-build-env-umwjd1xd/overlay/lib/python3.7/site-packages/cmake/data/CMake.app/Contents/share/cmake-3.13/Modules/CMakeTestCXXCompiler.cmake:45 (message):
    The C++ compiler
  
      "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++"
  
    is not able to compile a simple test program.
  
    It fails with the following output:
  
      Change Dir: /private/var/folders/dp/c9fjc9m107v4pqjyprys509h0000gn/T/pip-req-build-3bcrg19m/_cmake_test_compile/build/CMakeFiles/CMakeTmp
  
      Run Build Command:"/private/var/folders/dp/c9fjc9m107v4pqjyprys509h0000gn/T/pip-build-env-umwjd1xd/overlay/bin/ninja" "cmTC_36143"
      [1/2] Building CXX object CMakeFiles/cmTC_36143.dir/testCXXCompiler.cxx.o
      warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]
      1 warning generated.
      [2/2] Linking CXX executable cmTC_36143
      FAILED: cmTC_36143
      : && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++  -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -mmacosx-version-min=10.6 -Wl,-search_paths_first -Wl,-headerpad_max_install_names  CMakeFiles/cmTC_36143.dir/testCXXCompiler.cxx.o  -o cmTC_36143   && :
      clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of OS X 10.9 [-Wdeprecated]
      ld: library not found for -lstdc++
      clang: error: linker command failed with exit code 1 (use -v to see invocation)
      ninja: build stopped: subcommand failed.

I try to add the option -stdlib=libc++.

When I add it to CMakeLists.txt in either the top-level dir or the src/uharfbuzz dir via set(CMAKE_CXX_FLAGS "-stdlib=libc++"), it isn’t picked up.

When I set it in the bash environment, building still fails:

export CXXFLAGS="-stdlib=libc++"
pip install .
  CMake Error at /private/var/folders/dp/c9fjc9m107v4pqjyprys509h0000gn/T/pip-build-env-hsizem66/overlay/lib/python3.7/site-packages/cmake/data/CMake.app/Contents/share/cmake-3.13/Modules/CMakeTestCXXCompiler.cmake:45 (message):
    The C++ compiler
  
      "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++"
  
    is not able to compile a simple test program.
  
    It fails with the following output:
  
      Change Dir: /private/var/folders/dp/c9fjc9m107v4pqjyprys509h0000gn/T/pip-req-build-l72yy688/_cmake_test_compile/build/CMakeFiles/CMakeTmp
  
      Run Build Command:"/private/var/folders/dp/c9fjc9m107v4pqjyprys509h0000gn/T/pip-build-env-hsizem66/overlay/bin/ninja" "cmTC_adad8"
      [1/2] Building CXX object CMakeFiles/cmTC_adad8.dir/testCXXCompiler.cxx.o
      FAILED: CMakeFiles/cmTC_adad8.dir/testCXXCompiler.cxx.o
      /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++    -stdlib=libc++  -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -mmacosx-version-min=10.6 -o CMakeFiles/cmTC_adad8.dir/testCXXCompiler.cxx.o -c testCXXCompiler.cxx
      clang: error: invalid deployment target for -stdlib=libc++ (requires OS X 10.7 or later)
      ninja: build stopped: subcommand failed.

When I try to set the deployment target via export CXXFLAGS="-stdlib=libc++ -mmacosx-version-min=10.9" it is added to the compiler call, but before the other existing -mmacosx-version-min=10.6 option, so it has no effect.

Any ideas?

A suggestion.

I have a font that only has GPOS, cmap, head, maxp and post tables, which works perfectly fine for the default (ot) shaper, but crashes hard when specifying the coretext shaper on macOS.

Relates to justvanrossum/fontgoggles#144

(FontGoggles compiles this kind of minimal fonts on the fly to do shaping for UFO sources: metrics come from the source via hb callbacks, and outlines are directly drawn from the sources, too.)

I'll open a PR that reproduces the problem.

I think a nice addition would be to have a GlyphInfo.name or GlyphInfo.glyph_name attribute.

To get the glyph name, I currently need to use fonttools to extract the glyph order from the font.

Btw. what would be the HB call to get a glyph name from a glyph ID?

i jus used the example provided in the repo but the result was just unexpected i used to expect unicode string that i can work with it now it's just something like this "gid968=1@943,0+0" which is not very workable or provided with insights, so is there a way to get reshaped unicode as output ? or how to convert this "gid968" to unicode !

@adrientetar would you be ok to move uharfbuzz repo under the harfbuzz github organisation?

/cc @behdad

Also ot_layout_script_get_language_tags():

And ot_layout_table_get_script_tags():

This is the root cause of justvanrossum/fontgoggles#63

Funny thing: I just noticed this limitation in uharfbuzz a couple of days ago and wondered when we'd see a real-world report, and here we are :)

I'll try to write a fix.

https://harfbuzz.github.io/harfbuzz-hb-ot-font.html#hb-ot-font-set-funcs says it's already called on hb_font_create, which uharfbuzz.Font does. Does it need to be there?

IMO, get_glyph_shape() should be a method of Font rather than DrawFuncs. The first argument to hb_font_get_glyph_shape() is a hb_font after all.

I find it a little odd we ask the DrawFuncs to get the glyph shape. To me, the question is: "hey font, please give me the glyph shape, using these DrawFuncs as tools."

font.get_glyph_shape(gid, draw_funcs)

draw_glyph_with_pen() is also a Font method.

Is it worth changing, with a deprecation warning for the existing DrawFuncs method?

I brought this topic up on the Font Tools & Tech discord and was instructed to file an issue here for support of TrueType-flavored VFs built without the optional HVAR table. The original issue was described here: #19, though HVAR is not mentioned specifically in the issue title.

I believe the issue could be solved by using the hb_ft series of functions instead of the hb_ot series (which I've attempted in a fork of uharfbuzz, but had no success)

Not sure if this is a uharfbuzz-related issue (or an issue in harfbuzz itself), but on certain variable TTFs (examples below), the Font.set_variations method seems to have no effect on resulting glyph_positions.

Here’s the code I’m using (lightly modified from the example in this repo):

        face = hb.Face(fontdata)
        font = hb.Font(face)
        font.scale = (face.upem, face.upem)
        hb.ot_font_set_funcs(font)
        font.set_variations(axes) # axes is a dictionary
        
        buf = hb.Buffer()
        buf.add_str(text)
        buf.guess_segment_properties()
        hb.shape(font, buf, features) # features is a dictionary

I should note that setting features in the hb.shape function does seem to work as expected.

Quite possibly there’s something I’m doing incorrectly, but I’ve been unable to find any examples on the internet of open-source code using the hb_font_set_variations function directly. Everything I’ve seen, such as fontview which uses libraqm, seems to instantiate variations indirectly via the hb_ft_font_create_referenced function (worth noting that fontview does display these variations and glyph_positions correctly for all the fonts below).

From top-to-bottom, Obviously (correct positions), Mutator Sans (correct positions), Vinila (incorrect positions), Compressa (Trial version) (incorrect positions). All the fonts are at their max wdth & wght, and are returned from FreeType with the correct glyph shape variations. (The height of the pink bounding boxes is totally arbitrary, not a result of Harfbuzz.)

My harfbuzz is often not like your harfbuzz, so downloading and building a vendor harfbuzz isn't something I want uharfbuzz to do. Obviously it's a good idea for platforms where you can't be sure harfbuzz is installed already, but it's unnecessary in many cases when you can just link against the system version. Can we make that an option?