troika-three-text: feasibility of adding support for *limited* rich text rendering

[skinandbones]

I'm interested in using troika-three-text to render rich text (bold, italic, variable font sizes, etc.). I have developed a proof-of-concept using multiple troika instances (with my own layout typesetting, word wrapping, etc.) but it has many pitfalls and is less than ideal.

What is the feasibility of adding support for rendering rich text directly with troika-three-text?

It seems that the Typesetter could be extended since it is already splitting the text into similar runs and font styles. For now, I'm mostly interested in supporting a very limited set of properties which effect the fontConfig (font, fontSize). I'd be willing to ignore color and properties that impact the material and shader.

Is it a reasonable approach to do this at the typesetter or would more extensive changes be needed?

Note: I'm not mentioning the other work to define and parse a format, split things into similar runs, etc. That is all solvable :)

Thanks for the advice!

[lojjic]

It's definitely feasible, and you're exactly right that Typesetter would be the place to handle it since it's already set up to process the text in runs that can use different fonts/sizes/styles/weights/etc. It's really that "other work" you mentioned that's been keeping me from doing it. 😉

#65

[skinandbones]

@lojjic this is fantastic news. Thanks for the confirmation! If I move forward with this I'll add it to that issue.

[timluther]

Hi, I've been working on doing exactly this, which I require for a project I'm working on (I'll eventually fork and make that code available).

I've been having quite a few problems though. The first thing I've added is a ranged text offset property, similar in interface to the font colourisation (which I'm expanding into a style system), in order to have arbitrarily spaced blocks of text in the same draw call (I need to render millions of lines, so separate Text objects aren't suitable). My offsets resolve to a per-character index into a table of paragraph x,y offsets. At the moment I handle these in the shader but I'll probably just offset the vertices before they get there. Styles (which will involve colour, SDF softness, font size, outline etc.) I plan to implement as a uniform table and per character index - maybe not size thinking on it, that's probably better handled at the vertex construction stage.
I can see I need to manage 'PrevRunEndX' (as my offsets disturb that) and do some more work with bounds and formatting, perhaps introduce another object for multiple text-rects within a single Text object. However, I'm having real problems when a unicode character is encountered - it just messes up my indices and I end up with subsequent text offsetting in the wrong way. I think this might have something to do with 8bit and 16bit indices in UTF encoding (I've tried figuring out what's going on around the > 0xFFFF sections that test for this)
I've had some trouble following the flow of the code, the promises, callbacks and thread workers make figuring this out a little tricky. I can see that fontRuns and 'charResolutions' has some part to play but not sure what exactly - 'charResolutions' seems to be an array of chars of 0 and 1, do these refer to different texture pages?

From what I've said here, would you say I'm going about this in the right way?

[lojjic]

@timluther Ah yes, unicode surrogates always complicate things 😉

I don't know your exact use case but from your description it sounds like the new experimental BatchedText utility (example) might be a better way to go for you. The idea is you still treat your objects as separate Text instances which you can transform freely but it handles batching them together into a single draw call. It doesn't yet support some of the varying properties you mentioned, but your effort might be better spent adding that support than trying to hack it into the inline typesetter?

[timluther]

That's great, thank you! I'll try that and then work on my styles stuff. This is a relief, I was getting a bad smell around this, felt like I was doing it the wrong way (and what you've described is exactly what I do in my own C++ code)