Skparagraph binding

[HinTak]

Binding skparagraph and adding text decoration.
Fixes #225 and #224

@kyamagu this is operational in running
https://github.com/HinTak/skia-python-examples/blob/main/shape_text.py

which is a python port of upstream's

https://github.com/google/skia/blob/main/example/external_client/src/shape_text.cpp

Transplanted to build standalone against libskia as a shared library in

https://github.com/HinTak/skia-c-examples/blob/main/shape_text.cpp

Important note:
https://issues.skia.org/358587937
and its windows equivalent
https://issues.skia.org/307357528

• basically NONE of skparagraph is meant to be exposed outside of google's family of software, let alone stable API!

And other issues in
https://github.com/HinTak/skia-building-fun/blob/main/ReportedIssues.md

[HinTak]

Missing a lot of documentations and tests, but operational - in running that particular example. Since this is google's own example, we can at least hope that if they break it, they'll update the example and points towards a modification/update of the example code too.

[HinTak]

The skia-python example gives output which are pixels identical to the c++ example, if you take into account of how they load the same font differently. I haven't figured out how to use skparagraph with an exact font file, but that's a limitation of my python knowledge about sub-class'ing, rather than this pull. We might be able to get around it by adding a python FontMgr.OneFontMgr(filename) class static method to do the equivalent of the c++ subclassing on this line : https://github.com/HinTak/skia-c-examples/blob/15b3b2b9381df682fb84b1605cc447af88d46c3f/shape_text.cpp#L63 to give python code the ability of the c++ example of using a specific font file.

[HinTak]

@kyamagu m130 is out, and it is quite small. I intend to pull #265 (and therefore also #260) and #256 into this, and do the README.m129 / m130 here (and mention this as a m130 change although it was post m128 against m128). Do you want to review this pre-pull of those, or post? Or doesn't matter? The pulls are all updating separate area of code, so it is fairly obvious which is which, even if I join all of them together before review.

Still missing are some tests from this. Upstream hasn't changed much documentation wise.

[kyamagu]

@HinTak It's good m130 update is small. At a glance, the code change looks good to me. It doesn't matter whether to review before or after the pull. Thanks!

[HinTak]

@kyamagu ready to go - as usual, read Readme.m130 first is probably a good idea. This is inclusive of #265 , #260 and #256.

[HinTak]

Okay, test_paragraph.py failed on windows. I suspect it is the icu code which isn't used on windows; so let's just skip it for windows and see whether test_unicode.py fails too.

[HinTak]

It appears that on windows, icudtl.dat needs to be copied to a load path. There are fairly recent reports about using skparagraph on windows (with rust or c#, or just c) that needs this.

[HinTak]

Apparently the canonical place to get icudtl.dat is from ihttps://github.com/unicode-org/icu/releases , one of the data-bin-{l,b}.zip files. L/B for little / big endian, and it is versioned.

[HinTak]

Okay, the failure on test_unicode.py is clearer - it just fails to construct. This looks to be a generic skia problem and has been reported against other users of skparagraph on windows quite recently (flutter, rust-skia, skia-sharp), and they seems to suggest people to get the icudtl.dat file from somewhere. rust-skia seems to have an answer of embedding the file within rust-skia. For now I am just going to put an additional paragraph in readme.m130 , and just skip the tests on windows. @kyamagu

[kyamagu]

LGTM, thanks!

[HinTak]

Mac os intel:
2104 passed, 110 skipped, 11 xfailed, 27 warnings