add support for fallback CoreText shaper on OSX

[ralsina]

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

[anthrotype]

ah! interesting. note that this module doesn't use the system's libharfbuzz so it doesn't matter whether you have it installed with homebrew. I'll look into it.

[anthrotype]

oh right. We are compiling a static harfbuzz library with the default options, which on macOS will include -DHB_HAVE_CORETEXT:BOOL=ON; however, we are not also linking the extension module with the ApplicationServices framework (which includes CoreText shaper).

We have two options:

1) pass -DHB_HAVE_CORETEXT:BOOL=OFF and avoid linking with ApplicationServices; in this case, the coretext shaper will not be available, only the default harfbuzz open type shaper; 2) keep -DHB_HAVE_CORETEXT:BOOL=ON and add a target_link_libraries to link with the framework (only on macOS); this way, the coretext fallback shaper will be also available.

[anthrotype]

I'll go for option 2).

We need to check that on windows we don't incur in the same issue; there the uniscribe and dwrite shapers may be enabled by default in the harfbuzz CMakeLists.txt, and cause a similar linker error at import.

[anthrotype]

@ralsina please check that it works now. I'll tag a new release shortly. I'd like to write a basic smoke test to catch these things.

Note that we wrote the wrapper but haven't got the chance to use it much yet in the application we built this for (the maintainer of that is busy with other things at the moment). You may well be the only user ;)

[ralsina]

Hey, happy to help find the bugs ;-)

It seems fixed now.

[anthrotype]

actually.. it may make more sense to completely disable coretext fallback shaper instead (-DHB_HAVE_CORETEXT:BOOL=OFF), because currently in the uharbuzz bindings I don't see a way to select it. If it can't be used yet, better not link with it.

[anthrotype]

to support selecting the shaper, I believe we need to expose hb_shape_full and hb_shape_list_shapers

https://github.com/harfbuzz/harfbuzz/blob/3c2842cbcf8cded73d1e310379e1a4ca124a6fc2/src/hb-shape.h#L49-L57

[anthrotype]

hm.. maybe it's OK to link to the ApplicationServices framework, even if there is currently no way (from the python bindings) to force using the coretext shaper instead of the default one. I think it's still useful even if it's only available as a "fallback"... @khaledhosny what do you think is best?

[khaledhosny]

The coretext_aat shaper is automatically used for AAT fonts, so it will be used even if you don't manually select it (having the API to call control the shapers would still be nice though since one can then disable it if wanted, but even this can be controlled by an environment variable, HB_SHAPERS IIRC).

The Uniscribe and DirectWrite should not be enabled, though. They for easily comparing them with HarfBuzz and should not be used in production.

[anthrotype]

thanks @khaledhosny!

[khaledhosny]

This should be closed. HarfBuzz have native AAT support now and no user action is needed to enable it.