Text Curve: complex text layout

Archive Blender Development
1

Though this might not be used ultimately it can be a good experiment @Harleya

Update of @ideasman42 patch to be against current master
Current state:

  • Build succeeds
  • ASCII with builtin fonts works

still needs work, any help is appreciated

https://developer.blender.org/D13921

1 Like
2

Hate to spam your thread with lots of unrelated details but…

Non-ascii characters for text objects should be working now, in that all glyphs from all languages can be used. So this might be a typo and you mean “support language scripts that require complex shaping (like joining together) and those that are right-to-left”. If it does seem like you want to say “non-ascii” it could be the weird detail that we use a large font containing almost every language character for our interface, but the default one for text objects (bfont.pfb) contains very little.

I love the idea of getting that patch running, mostly to shake out other issues that we’ll have to deal with. We currently enter the text in the view itself but I think we’d eventually have to enter text in an regular text input somewhere. Otherwise we will have a difficult time supporting selection, caret movement, etc for text that changes direction. What I mean is the behavior you see when trying to select within the following text: “ניפגש ב09:35 בחוף הים” or this “I can write English with מילים בעברית in the same sentence.” And yes, your browser is doing this properly.

I have a personal list of items to fix in order. ⚓ T94030 Font Changes (Parent Task). The reason for the ordering can seem arbitrary, but there are some reasons behind them. We support text output in two completely different systems (bfont used in the interface, and vfont used for text objects). I’d like the remove that duplication and allow bfont to export curves. We could also then remove “bfont.pfb” and let users select from our regular font stack instead by default.

I am also hoping to support some complex font features like fallback, variable fonts, etc. For this to be done right we would need the flexibility of directly using FriBiDi and Harfbuzz directly, rather than through a wrapper like the libraqm in that patch.

Bfont text output is currently working on UTF-8 strings, outputting glyphs by codepoint. In order to support FriBiDi and Harfbuzz we’d have to change to outputting substrings (per script) as arrays of glyph indexes. This conflicts a bit with our current caching of glyphs by codepoint. If we instead cache the glpyhs by glyph index then we lose quick codepoint-to-glpyh index lookup, but I am hoping to fix that by the use of the FreeType Cache subsystem.

There’s probably lots of other details, but this is all I can think of at this moment.

6 Likes
3

Nope it is very related, great sum up of things.
Yep just renamed the title from non-ascii

1 Like