[Feature Request] Simplify `TextLine` FTE (Flash Text Engine) usage

[itlancer]

Feature Description

Please consider to simplify TextLine FTE (Flash Text Engine) usage with some helper class like TextField. Cause right now it's very hard start to use FTE. https://airsdk.dev/docs/development/text/using-the-flash-text-engine It will help a lot of developers.

Related issues: https://github.com/airsdk/Adobe-Runtime-Support/discussions/1699#discussioncomment-12552934 https://github.com/airsdk/Adobe-Runtime-Support/issues/3508 https://github.com/airsdk/Adobe-Runtime-Support/issues/3191 https://github.com/airsdk/Adobe-Runtime-Support/issues/2744 https://github.com/airsdk/Adobe-Runtime-Support/issues/2562 https://github.com/airsdk/Adobe-Runtime-Support/issues/2201 https://github.com/airsdk/Adobe-Runtime-Support/issues/867 https://github.com/airsdk/Adobe-Runtime-Support/issues/56

[ylazy]

Yeah it would help me too. RTL languages support and advanced text formats like strikethough, superscript, subscript, emojis, paragraph spacing... I need them, mordern applications need them and users need them too. But I understand that it would require much efford...

[waveofthought-code]

is TLFTextField no longer viable?

legitimately curious because I need to implement colored emojis once they work with "direct" renderMode

[ajwfrost]

I think TLFTextField is just a bit heavy. Plus unsupported..? I believe it was a SWC library that was provided as part of Flash Professional/Animate but afaik it's no longer available. Not sure about the source code...

[ylazy]

I found the swcs here TLFTextField is heavy and full of bugs, so it was deprecated 11 years ago. The Text Layout Framework is not a GPU-based lib, so it's hard to build a fast TLFTextField. I think we need something like Slug - as I suggested

[ajwfrost]

I'd looked at that Slug library, it looks pretty good. Not quite sure how the licensing might work out though, if we were to include this in the AIR SDK directly, but it might be something we could do the integration for and then leave it up to individuals to see if they want to use it.

The only thing I couldn't see whether it was possible with Slug - and I'm not 100% sure whether it's going to also be a request here - is about text input fields. We have two possibilities with text input:

1. Use the native OS-specific input controls - like for StageText, but I think in some other instances, the runtime just puts an OS control over the top of the internally-rendered area and uses that for handling all the native stuff like cut/copy/paste etc.
2. Handle all the navigation/selection/insertion ourselves, and then just paint the updated text data every time something changes, along with a blinking caret.

Probably with Slug we're more likely to need to do the latter; the former option can mean slight changes between when you're in 'edit' mode and when you've moved the focus away from the text field.

Going back to the idea of simplifying the FTE usage to create a control like TextField but that has the extra capabilities - I can ask someone to look into it, but the first step would be to create a component to do this via the existing FTE classes (i.e. hiding the functionality internally), and we can then look to see what could be optimised (beyond just moving it to C++). And because FTE doesn't have the "input" type, would this be a restriction that you would be okay with i.e. we could create a dynamic text field but not an input one?

thanks

[itlancer]

And because FTE doesn't have the "input" type, would this be a restriction that you would be okay with i.e. we could create a dynamic text field but not an input one?

@ajwfrost, for me it's ok for the start. But it good to have it later then.

[ylazy]

In my apps, I have no issues with input TextFields/TextAreas. In most cases, users only need to input a small amount of text. Handling navigation/selection/insertion myself is okay with me too. I think the only case in which we want to display a large amount of editable text is a code editor. In this case, I would spend my time building a library for that use.

[waveofthought-code]

I can't speak to how important this is for others, but for me the ability to render html text like a TextField is crucial. I'm stuck in this weird limbo where TextField can do html text but not colored emojis, while TextLine can do colored emojis but not html text!

[Ender22]

We really need 1 textfield class to rule them all, in my app all my textfields have to be a parent container class MultiTextField, then if its normal text it renders with a normal Starling TextField, then if they contain emojis we render an emoji supportive feathers type of textfield (but then it cant display with our embedded font, or html so it looks bad), and then if it contains arabic we use a RTL supportive style textfield (but then emojis and HTML don't work and also some alignment stuff isn't supported)

Rendering text in Air really is a nightmare if you try to support emojis, HTML elements, and multiple languages