search

kyamagu / skia-python

Python binding to Skia Graphics Library
https://kyamagu.github.io/skia-python/
BSD 3-Clause "New" or "Revised" License
238 stars 42 forks source link

typeface.getVariationDesignPosition() not working as expected #113

Closed justvanrossum closed 1 year ago

justvanrossum commented 4 years ago

Describe the bug The return value of typeface.getVariationDesignPosition() contains a stray item, and does not give the expected result at all on Linux.

To Reproduce I have created a tiny test project here: https://github.com/justvanrossum/skia-vf-bug

Expected behavior I expected the test script to output this:

MutatorSans.ttf
{b'wdth': 0.0, b'wght': 0.0}
IBMPlexSansVar-Roman.ttf
{b'wght': 400.0, b'wdth': 100.0}

This should show the VF design position of the typeface (in this case the default).

However, on macOS and Windows the output is:

MutatorSans.ttf
{b'wdth': 0.0, b'wght': 0.0, b'\x00\x00\x00\x00': 0.0}
IBMPlexSansVar-Roman.ttf
{b'wght': 400.0, b'wdth': 100.0, b'\x00\x00\x00\x00': 0.0}

That is easy to work around. However, on Linux it outputs this:

MutatorSans.ttf
{b'\x00\x00\x00\x00': 0.0}
IBMPlexSansVar-Roman.ttf
{b'\x00\x00\x00\x00': 0.0}

Desktop:

Additional context I alluded to this problem in #112, and in justvanrossum/drawbot-skia/issues/1

justvanrossum commented 4 years ago

I managed to rewrite my code so it doesn't rely on typeface.getVariationDesignPosition() anymore, and fontargs.setVariationDesignPosition() works perfectly, so this is no longer a blocking issue for me. Feel free to close or reclassify as feature request.

kyamagu commented 4 years ago

Thanks for reproducing this, let's keep this issue open since the fundamental issue isn't yet resolved

kyamagu commented 4 years ago

This is likely due to an internal fontconfig issue. Need to check if fontconfig version matters.

justvanrossum commented 3 years ago

FWIW: as of 87.1, this issue persists on Linux, but seems to have been resolved on Win and Mac.

HinTak commented 1 year ago

Not a fontconfig issue but a freetype issue. According to Skia's c++ source code, this routine has at least 3 different implementations - directwrite, coretext, freetype, being 3 of them... likely freetype too old on the wheel.

HinTak commented 1 year ago

I think I know exactly why this is broken - if you get the wheel prebuilt skia-python binary from pip, it uses the "locked" freetype version bundled with m87. So until and unless you build skia-python entirely from source, and make it depends on your system's up-to-date freetype (I have such an option in my private fork), or you switch to a much later skia (with a much later Locked freetype version), you are stuck with this bug.

HinTak commented 1 year ago

The line to change is around https://github.com/kyamagu/skia-python/blob/5d927433afb607bff4a97d9a7e5b792b83ecedce/scripts/build_Linux.sh#L57 , and also additional linker flags in the main setup.py. I see the pip-installed skia-python m87 has a private copy of very old freetype (2.8, i think - I dug it up properly and commented elsewhere) rpath'ed in its own private directory under pythonlib.

HinTak commented 1 year ago

Actually you might be able to fix it in the pip wheel, by patching skia's DEP file, to bundle a different freetype version.

HinTak commented 1 year ago

Those are relatively new routines in freetype so the version of freetype definitely matters.

HinTak commented 1 year ago

My system's freetype is up to date but I ended up having to make such a change to make m116 build in CI https://github.com/kyamagu/skia-python/pull/196/commits/8cf897ff91f329961c7e5b3ad68dd82c3c0dc63e - this might give you some idea what to do if you want to fix m87.

HinTak commented 1 year ago

This seems to be fixed with 117bx (and possibly with 116b2) .