Hi! In the company I work for we've recently begun...

# compose

[Jesper Åman]

Hi! In the company I work for we've recently begun the process of adopting Compose, part of this process includes creating Compose counterparts for themes and components from our design system. As a strategy for ensuring visual parity between the standard UI toolkit implementation and the new Compose implementation, we're trying out snapshot testing with Paparazzi; we record snapshots of standard UI design system components as golden values, and verify them against their new Compose counterparts.
While trying this out we've discovered some potential discrepancies in how text is laid out in the standard UI toolkit vs. Compose - particularly, there seems to be slight differences in default letter spacing (for non-monospaced fonts) as well as line height, the line height we can match, it's mainly the letter spacing that becomes a problem.
What I'm wondering is: is this a) known/intended behaviour? b) a bug? c) me missing something? d) perhaps a layoutlib specific issue? e) something completely different?
To illustrate what I'm talking about I've attached two simple text views that are being matched as well as the diff between them. In the diff the left snapshot (Expected) is from the standard UI toolkit and the right one from Compose. It appears that both letter spacing and line height is slightly less in Text from Compose.

[Siyamed]

thanks for detailed description.

the difference for letterspacing is that on compose side we use a Span (https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:text/tex[…]xt/android/style/LetterSpacingSpanEm.kt?q=LetterSpacingSpanEm) where as platform is using directly function on Paint (https://cs.android.com/android/platform/superproject/+/master:frameworks/base/graphics/java/android/graphics/Paint.java;l=1821?q=Paint.java)

[Siyamed]

The screenshots seems to be showing the difference of both of them (letterspacing and lineheight) therefore I wasnt sure about what exactly is different for letter spacing

[Siyamed]

the difference between Span vs TextPaint "might" be causing a difference. Even though I don't remember the reason why we implemented it as a span, it is related to the correctness of the overall final result.

[Siyamed]

since you mentioned that line height is solvable by configuration; i will appreciate if you can create a ticket with the screenshot (not the above one but one with only letterspacing difference). We will check when available.

[Siyamed]

Even though I am not sure if the difference is because of a bug (or depends on platform version) or working as intended; a similar expectation has been discussed before with includeFontPadding: Compose Text does not have the goal to be pixel perfect equivalent of platform.

[Jesper Åman]

Thanks for the reply, @Siyamed

the difference between Span vs TextPaint

I came across this myself yesterday as I was digging a bit deeper in the Compose code, thought this might be the culprit. One thing I saw that may or may not be related was this:
https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]anStyle.kt;drc=40bca873ee88887caf34da1a1aaee93cb6ddc7b6;l=727
Essentially interpolation between letter spacing from two different spans, seems like a potential source of inaccuracy.
I would assume this is not what is causing the discrepancy in my case since we're probably not dealing with multiple spans here?

i will appreciate if you can create a ticket with the screenshot (not the above one but one with only letterspacing difference). We will check when available.

Great, I'll go ahead and do that.

Compose Text does not have the goal to be pixel perfect equivalent of platform.

Yeah I think that makes sense, and these discrepancies are pretty much indiscernible to the human eye. I just thought it would be nice if it was possible to get a pixel perfect match in order to appease the snapshot tests and have more confidence in the migration process.

[Jesper Åman]

So get this, I did some further digging and experimentation and found that this does not happen for all text sizes, e.g. 20sp, 24sp, 30sp all produce pixel perfect matches, but 21sp, 23sp, 25sp, 26sp, 27sp etc produce the discrepancy.
Moreover, the discrepancy is only produced when these text sizes are declared in XML(!); when programmatically setting the text size it goes away.
So, it seems like this is not an issue with Compose after all, but rather the initiation process of TextView when reading attributes from XML (and I would assume that this never manifests at runtime, it likely sorts itself out by the next layout cycle).
I've created a reproducible example here:
https://github.com/jeppeman/SnapshotDemo
I guess I can skip submitting an issue then @Siyamed, or is this something you want to investigate and fix anyway? cc @Mikael Ohlson