Why are text measurement APIs exposing `IntSize` f...

# compose

[louiscad]

Why are text measurement APIs exposing IntSize from a ceilToIntPx() call rather than keep the decimals in a Float?
When text is animated (and therefore has the subpixel flag), it leads to non-pixel perfect things.

[romainguy]

You can animate rendering using floats, that’s unrelated to the measurement

[louiscad]

My use case it drawing text on a path, and splitting it to multiple calls to drawTextOnPath (Android's Canvas platform API) for each span.

[romainguy]

I haven’t tried drawTextOnPath in a while but it was horribly broken in some cases

[romainguy]

(and in some cases you can’t do better anyway, drawing text on a path is fundamentally problematic)

[louiscad]

This is from a test along an arc. Magenta is all in one call, light gray is when drawing character per character, and offsetting from previous characters.

The one with green is the same as the other one, but the light gray is behind because I removed 1, essentially turning the ceil into a floor.

[louiscad]

Is drawTextOnPath as broken as what this would produce?
https://www.pushing-pixels.org/2022/02/10/drawing-text-on-a-path-in-compose-desktop-with-skia.html

No other way on Android anyway, just curious

[romainguy]

yeah

[louiscad]

I could also leverage PathMeasure to draw text character per character on a path, would it be as broken?

[romainguy]

look at the blue text

[romainguy]

it’s on a concave curve

[romainguy]

so depending on the height of the glyphs, they can overlap for instance

[romainguy]

cusps are also an issue, etc.

[louiscad]

I've seen that for overlapping on concave

[romainguy]

splitting the measurement is going to be an issue because of the nature of text (ligatures, etc.)

[louiscad]

My use case is mostly to draw on convex paths though

[romainguy]

but even without splitting, there are problems

[romainguy]

even a convex path can look horrible

[romainguy]

take a small circle and draw text on the circle using a large font

[louiscad]

That's intrinsic to drawing text on a path

[romainguy]

it looks silly

[romainguy]

etc.

[louiscad]

You can draw text on a triangle path, it'll also look not nice

[romainguy]

Skia has/had a way to “morph” the text along the path, but that also looked strange in some cases

[romainguy]

You can actually do that using public Compose APIs, by drawing the text as a stamped Path on a Path

[louiscad]

And that, kids, is why the Apple Watch is square.

[romainguy]

No it’s not 🙂

[louiscad]

Haha, yes, it has corner radius

[romainguy]

(esp. since they have a bunch of circular watch faces)

[louiscad]

True

[louiscad]

Was just kidding

[louiscad]

Drawing text as a stamped path?
What do you mean?

[romainguy]

https://www.youtube.com/watch?v=gtQsC1bav5M▾

[romainguy]

16:30

[louiscad]

I think I was there in person at your talk 😄
Recall that fun animation, but didn't realize it could be hacked to draw text on a path.

I'm not sure I see how to get the path of a glyph from TextLayoutResult though…

[louiscad]

My current workaround for my initial question is to call getBoundingBox on the TextLayoutResult and passing the last index of the previously drawn chunks to it.

It's still not pixel perfect, but the difference is negligible

[louiscad]

It's sad that this ceil operation is applied though, I can see the code of getBoundingBox is non trivial, certainly much more expensive to compute something that was already known but couldn't be retrived because of inpenetrable API boundaries.

[romainguy]

I wouldn't worry about being pixel perfect

[louiscad]

You would just subtract 1 to the ceiled result to avoid making longer than necessary?

[romainguy]

No i wouldn't do anything

[louiscad]

So you would let the text be a little longer than necessary?

Like on my previous screenshot with magenta text where the gray one goes a bit farther?

[romainguy]

Text on a path won't be "correct" anyway so 🤷‍♂️

[romainguy]

Like you assume that drawTextOnPath is "correct". It does its best but... :)

[louiscad]

I know, I'd also like to help it do its best, and I'm fine with the caveats

[Halil Ozercan]

if you are going in TextLayoutResult +`getBoundingBox` direction, you might want to take a look at https://gist.github.com/halilozercan/cf09d8c1ea6ec68264c031731f8eeb38

[Halil Ozercan]

here you can find a similar approach with a draw text on path logic https://github.com/halilozercan/madewithcompose/blob/main/app/src/main/java/com/halilibo/madewithcompose/textonpath/DrawTextOnPathDemo.kt

[louiscad]

Interesting!
I see this doesn't use Android specific code, which would enable me to avoid relying on Android-only APIs, letting me make an iOS or WASM app for something I have in mind

[louiscad]

About my almost pixel perfect match when using getBoundingBox, I noticed that when I have skewX set to something other than 0f (e.g. Float.MIN_VALUE, aka 1.4E-45f), the per-character split and non-split text render (with drawTextOnPath called for whole string vs for each char) match up perfectly. I'm not sure why, but it's good to know for me.

I still plan to look into Halil's per-glyph rendering solution because I believe it'll work best with emojis, exotic unicode stuff, and non latin text (like arabic or japanese).

[romainguy]

I wouldn't rely on this especially across platforms and API levels

[romainguy]

The main reason it does that is probably the rendering pipeline disabling pixel snapping when there's any transform set on text

[Halil Ozercan]

I also wouldn't recommend that approach if you are going to use it in an uncontrolled environment in production, e.g. the text is set by the user. getBoundingBox is not perfect. You may see some pixels of glyphs being left out especially for tall ascents and deep descents. getBoundingBox is not meant to be pixel perfect though. Its main purpose is to give a good approximation of where a character/glyph is in the text layout rectangle for focus, semantics, and gestures. In those cases missing a pixel or two wouldn't hurt. However when drawing it's not acceptable to leave a pixel behind while translating, rotation a glyph.

[louiscad]

I have been able to combine your gist and your DrawTextOnPathDemo both linked above to get a nice API that renders text on a path, while supporting all Compose text features, and without breaking emojis, as you can see on the screenshot!

Thank you so much Halil for the help, and thanks Romain for outlining the limits of drawing a text on a path.

BTW, while working on that, I noticed that nextContour() isn't exposed in Compose's PathMeasure API. I'm not sure why, but I think it could be helpful to have it, so I filed a feature request: https://issuetracker.google.com/issues/334977827

[romainguy]

PathMeasure has other issues anyway, I would like to swap out its implementation eventually to not rely on the platform’s

[romainguy]

Anyway you can work around this problem by using the new API in Compose 1.7 that lets you divide a Path into a list of contours (as Path instances) and measuring them individually

[louiscad]

Hum, what are the other issues PathMeasure has?

[romainguy]

It doesn’t let you specify the error metric, which means it’s basically useless for any path that’s not expressed in pixels

[romainguy]

(for instance, if your path is in the 0..1 range, the length will always be the same, sqrt(2) )

[louiscad]

"error"?

[romainguy]

See https://developer.android.com/reference/kotlin/androidx/compose/ui/graphics/PathIterator#tolerance()

[romainguy]

There’s a similar error metric used when measuring the length of a path

[romainguy]

And by default it’s set to 0.5 (or 0.25 I don’t remember which one)

[romainguy]

Anyway, now we have more robust primitives in Compose we could use to improve PathMeasure (and probably making it faster too)

[louiscad]

Interesting

[louiscad]

I'm doing everything in pixels at the moment, right at render time, so it's not so much of a problem for now, but it's good to know those subtle caveats nonetheless.

[louiscad]

I'm now wondering is there is a way to morph the glyphs, with the Compose DrawScope and text APIs. It might not always be what I want, but it'd be cool to have the choice

[romainguy]

I’ve been playing with that recently and it’s complex problem to solve generally, esp. if you morph across typefaces. You won’t get any morphing for text out of the box though

[romainguy]

(some of the APIs added recently — divide, reverse, path iterator etc. — are precisely to be able to build this capability)