Bidi as components

[verzuz]

This is an alternative implementation to https://github.com/bevyengine/bevy/pull/4614 - I would like to find out which is more favorable.

Objective

• short: unicode bidi support for text and text2d
• When text is presented in horizontal lines, most scripts display characters from left to right. However, there are several scripts (such as Arabic or Hebrew) where the natural ordering of horizontal text in display is from right to left. If all of the text has a uniform horizontal direction, then the ordering of the display text is unambiguous. However, because these right-to-left scripts use digits that are written from left to right, the text is actually bidirectional: a mixture of right-to-left and left-to-right text. In addition to digits, embedded words from English and other scripts are also written from left to right, also producing bidirectional text. Without a clear specification, ambiguities can arise in determining the ordering of the displayed characters when the horizontal direction of the text is not uniform. This is solved by the Unicode Bidirectional Algorithm.

Solution

• using the unicode-bidi crate and keeping corrected TextSections in a new component

[verzuz]

I prefer this version of the implementation and hopefully we can find a way to not have two duplicate implementations :)

Good work!

Thanks - I agree - it seems more in line with the ECS. The dublication is annoying me - I'll have another look at it how we can solve this.

[verzuz]

Ok so first of all: I hope I didnt mess up the merge. BidiCorrectedText now exists only in the Text crate and is public again - which allows for the systems to be public. This might allow the user again to fiddle with it, but the component itself atm is only added and updated in the text systems. I moved the TextSection -> BidiCorrected into a function of BidiCorrectedText so we reduce the dublicated code.

[TimJentzsch]

The code looks good to me with the newest changes!

The most controversial aspect about this would IMO be the added asset file and it's licence which I'm guessing would need the signing off by cart

Probably best to still let Cart sign this off, but the FiraSans font we use already has the same license so I doubt it will be an issue :)

[TimJentzsch]

I was thinking, in the future when we have better support for text shaping and other internationalisation features, how are we going to combine those features (or rather the caching)?

I assume we are going to be able to cache stuff for those as well. Are we going to have components for each of them or one combined "text cache" component or something like that? I assume they will all depend on each other and change together once the text changes.

[Weibye]

I was thinking, in the future when we have better support for text shaping and other internationalisation features, how are we going to combine those features (or rather the caching)?

I assume we are going to be able to cache stuff for those as well. Are we going to have components for each of them or one combined "text cache" component or something like that? I assume they will all depend on each other and change together once the text changes.

While I think this is a very good short-term solution, we are going to have to revisit the whole text-pipeline when we want to add more higher-level features. I don't think we have a clear enough idea of what that would look like yet to gain anything from blocking this PR.

[verzuz]

I was thinking, in the future when we have better support for text shaping and other internationalisation features, how are we going to combine those features (or rather the caching)?

I assume we are going to be able to cache stuff for those as well. Are we going to have components for each of them or one combined "text cache" component or something like that? I assume they will all depend on each other and change together once the text changes.

For me this is more of a "lets add this feature to get a feel for it". Looking at the whole picture of text rendering, we will probably have to refactor this to get it into a coherent text pipeline with text shaping etc. But at least we have RTL for now and we already have an example how it might work. At the moment my guess would be, that we have separate components and systems for each step which can be used as pipeline (although I would hope that an experienced user gets the option to pick and choose which features they want to use).

[TimJentzsch]

Sounds good, we can revisit that once we are adding more features to our text pipeline :)

[verzuz]

Can we store a single Vec<TextSection>> in the Text field, following the approach taken in #4614? Why do we need to keep the original text around at all?

I personally would not want to touch the original data since the user might want to read it later and changing it "behind the scenes" can cause unforeseen consequences.