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? (text: Rendering texts correctly in Arabic/Thai/Hindi... #675)
• A new API should be able to render text outlines (Outline / Stroke text font #1937)
• A new API should treat text aligns (text: a utility function to render texts with a left-upper position #2143)
• A new API should resolve some existing issues (text: Used fonts are never discarded #498, text: crash with an unhashable face #2669)
• A new API to use preinstalled fonts (enable to use pre-installed fonts in each system #788)
• A new API to convert a position from/to a text index (text/v2: utility APIs for text fields #2834)

[hajimehoshi]

We might add text/v2 to keep the compatibility. (See also golang/go#60751 (comment))

[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.