What’s the rationale behind `TextIndent` indentati...

# compose

[Mark]

What’s the rationale behind TextIndent indentation values being TextUnit? The problem here is that TextUnit does not scale linearly, so we can’t just double the value to get double the margin size. To fudge it, we need access to the Density.

[Stylianos Gakis]

Probably because it needs to be adjustable to the current system's font size preferences.

If what you want to use is a hard value it won't scale properly across all font sizes, isn't that the case?

[Mark]

A better way would be to have a lambda with the current fontSize (and Density) passed in and then returns a pixel value. If I want to have indentations of about 4 character widths (e.g. based on half-width characters) then I can’t just calculate a value for 4 characters and then scale up for double-level, triple-level indentations etc. TextUnit best describes the size of a character/glyph, not an indentation size.

What to do now? Suppose I guess that a character is 10.sp, and I want about 4 characters to represent a single-level indent. I can’t just use 40.sp because that is probably much less than 4 characters. And it gets worse and worse as you get 2, 3, 4 or more levels deep. Note, this is relevant even when fontScale is the default (1f), thanks to changes introduced in Android 14.

https://developer.android.com/about/versions/14/features#non-linear-font-scaling

[Alex Vanyo]

Does using `.em`s work for your case?

[Mark]

I guess this would mean I don’t need to know the current font size, so yes thanks, that helps. However, it don’t think it solves the non-linear scaling, right?

[Mark]

Actually, no, em doesn’t help because that can’t be converted to px in order to do the workaround of working out an indent corresponding to, say, 4 characters. What I would like to declare is something like indentSize = 4 half-width characters, indentCount = 3

EDIT: I just confirmed that specifying 1.em throws: IllegalStateException: Only Sp can convert to Px from compose