npillmayer / uax Goto Github PK

I've take a look at Gio and have been impressed. Then I did some experiments by coding little samples and have been impressed even more.

Following the discussions about licensing for gu-text, I'll change my license to be fully compatible with Gio.

Hi Norbert!

We've recently merged complex script support in Gio, and (predictably) this means lots more people are playing with it and noticing the side effects of the change. One of the major side effects looks like a 4MB binary size increase. There are many contributors to that binary size hike in go-text/typesetting, but the single largest one is the tables defined in this file. Would you be open to a feature that compresses those tables when they're generated and decompresses them at init time? Would that be an acceptable default behavior if so?

Cheers!

Hi @npillmayer,

This is a valuable and ambitious project! Go sorely needs high-quality implementations of various UAX algorithms, as well as a number of other important improvements to its handling of text.

The @go-text organization is a collaboration of gophers (many from @gioui or @fyne-io) trying to improve the state of text rendering in Go. We want for GUI/Graphical applications in Go to be able to properly handle international text. We've mostly been working on text shaping, but will need good BiDi, line-breaking, and other algorithms in order to meet our goals.

Would you be interested in collaborating with us? I think we each have part of a good text stack, and putting them together may bring us much closer to a complete one.

I guess there’s an impedance in the API: pass in runes and get out bytes. That’ll require the client to re-process the output to chunk it into runes again. That’s easily been done from a coding perspective, but it is nevertheless work that should be avoided, as UAX is always handling runes already. I’ll think about a zero alloc interface where clients are allowed to put in a rune-buffer and get out a slice of runes.

Hi @npillmayer !

I've been working to integrate my shaping changes into Gio core, and I noticed that importing UAX dramatically increases the size of Gio's go.sum (we work hard to keep it small). It looks like the usage of schuko outside of test code in UAX is forcing us to import its transitive dependency tree (even with go 1.17 module pruning). Is there anything we can do to slim this down?

As always, thanks for the great library!