`BasicTextField2` API question. Is `InlineTextCont...

# compose

[Sergey Y.]

BasicTextField2 API question.
Is InlineTextContent can be alternative to ReplacementSpan?
Details in the thread 🧵

[Sergey Y.]

In my project, which shares similarities with basic vector editors, I work with vector graphics on a canvas-like layout, where a user can add vector shapes and text with various fonts, including non-file-based fonts.
We are using a custom text shaping engine that generates ready-to-draw glyph path objects, encompassing all necessary data such as character rectangles, text runs, etc.
Previously, we used EditText with ReplacementSpan to swap characters for rectangles, effectively matching our custom text shaping engine outputs (like character rectangles) for fonts not supported by EditText. Users saw the shaped text graphics instead of raw text, and it worked perfectly for cursor positions and canvas graphics.

Before ReplacementSpan:
"text"

After ReplacementSpan:
[ ][ ][ ][ ] <- Each rectangle represents a character's width

We're trying to shift to BasicTextField2 but can't figure out how to replicate the character replacement with specific widths like we did with ReplacementSpan. Any tips or guidance on achieving this with BasicTextField2?

Something somewhat similar I can get from the onTextLayout callback, within textLayoutResult, called placeholderRects: ListRect, but this is opposite to what I need. I'm looking to set such already calculated rect placeholders to the BasicTextField2, not just read them.

onTextLayout = {
    val textLayoutResult: TextLayoutResult? = it()
    val placeholderRects: List<Rect?>? = textLayoutResult?.placeholderRects
}

[Sergey Y.]

Screenshot 2024-02-21 at 00.01.33.png,Screenshot 2024-02-21 at 00.00.59.png

[Sergey Y.]

I've also explored the codepointTransformation and outputTransformation features within BasicTextField2.

However, upon closer inspection, these APIs don't seem to provide the level of control over text layouting that ReplacementSpan offered in the traditional EditText setup. Specifically, they don't appear to allow for the detailed manipulation of the text layout process to override necessary parameters for our custom text shaping and rendering needs.

[Sergey Y.]

image.png

[Sergey Y.]

https://kotlinlang.slack.com/archives/CJLTWPH7S/p1701005034715179?thread_ts=1700969518.715199&cid=CJLTWPH7S

[Sergey Y.]

Oh, that is unfortunate. Looks like we have to stick with EditText wrapped in AndroidView for interoperability.