text: redesign APIs (text/v2)

[hajimehoshi]

Operating System

• [ ] Windows
• [ ] macOS
• [ ] Linux
• [ ] FreeBSD
• [ ] OpenBSD
• [ ] Android
• [ ] iOS
• [ ] Nintendo Switch
• [ ] Xbox
• [ ] Web Browsers

What feature would you like to be added?

No concrete plan, but there are multiple better text APIs than golang.org/x/image/font. Let's investigate this.

• https://github.com/go-text/typesetting
• https://github.com/benoitkugler/textlayout
• https://github.com/tdewolff/canvas
• https://github.com/tinne26/etxt

Why is this needed?

The current text APIs are not matured e.g. this lacks layoutings.

[hajimehoshi]

• A new API should accept both sfnt.Font and typesetting's fonts.Face to get vector data.
• A new API should accept a layout engine like HarfBuzz, but apparently this doesn't accept sfnt.Font? (#675)
• A new API should be able to render text outlines (#1937)
• A new API should treat text aligns (#2143)
• A new API should resolve some existing issues (#498, #2669)
• A new API to use preinstalled fonts (#788)
• A new API to convert a position from/to a text index (#2834)

[hajimehoshi]

We might add text/v2 to keep the compatibility. (See also https://github.com/golang/go/discussions/60751#discussioncomment-6158369)

[hajimehoshi]

I am now working on a GUI application with Ebitengine, and I would like to plan the new API based on my experience of this. So, I need more time.

[hajimehoshi]

Another consideration is to enable variables https://pkg.go.dev/github.com/go-text/typesetting@v0.0.0-20230803102845-24e03d8b5372/opentype/api/font#Face.SetVariations (e.g. https://rsms.me/inter/#features)

EDIT https://pkg.go.dev/github.com/go-text/typesetting@v0.0.0-20230803102845-24e03d8b5372/opentype/api/font#Feature is the correct link

[tinne26]

To be fair, font variations are a very questionable feature. If support for any single feature should be added, colored glyphs and embedded bitmaps would be much more relevant than font variations. The open type format is already very bloated, but font variations must be one of its most unnecessary and gimmicky features. They can be used in ways that seem logical, but outside tech demos, in real world scenarios, you just use two or three different font weights instead. Many type designers are skeptical of variable fonts and consider them gimmicky. Others say it may revolutionize text animation, but there's no sign of that yet. Maybe because it turns out that... that's not practical with CPU rasterization.

In conclusion, I think that font variations should be considered, at most, a very low priority issue. Also, if you cross that threshold you may also have to start considering separate text/sfnt/render and text/typesetting/render packages, because otherwise the feature support across the public API may become swiss cheese.

[hajimehoshi]

To be fair, font variations are a very questionable feature.

Is that true? I came up with one use case (e.g. tabular numbers for GUI applications). I'll consider this when I really need. Or, even I don't implement this, I'll leave API to be extensible for the future.

[hajimehoshi]

I'll try to write a design document this week for text/v2.

[hajimehoshi]

https://docs.google.com/document/d/1sEuNezPULkR60jk89QHfQ7hhoyuPgKRfZ-CpqnoidWI/edit?usp=sharing

I've written a design document for the proposal text/v2. Feedbacks are welcome!

[hajimehoshi]

Almost done. Let me close this. For other remaining tasks, use other issues.