A modern programming language that makes developers happier.

kotlinlang

image.png

I've read through the very interesting thread <https://kotlinlang.slack.com/archives/CJLTWPH7S/p1617664367220300>. I'm using the experimental text UI and have implemented the suggestions of explicitly setting `includeFontPadding = false` and `lineHeightStyle` (the former does help a bit, the latter makes no difference, probably because my text is a single line), however I still get a lot of padding above and below my text. Is there a way to make that space smaller?

I wonder if you mean the empty space below the text 100 as padding?

If so that doesn't seem to be padding but the bounds of letters. 

If what you need is to completely remove all empty space and have a boundary that fits '100' exactly, there isn't a way of doing it in Text.

Yes, the empty space below, as well as above. You're saying that space is part of the font to handle things like ascenders and descenders?

What is the best workaround? The text is dynamic so I can't simply create an SVG from Inkscape or anything like that.

not recommended but hail mary solution could be to draw the text on a bitmap (major performance drawback) and crop dead rows(all pixels unaltered) from bottom and top

If you know that they wi always be numbers, qnd if you know the font will not have descenders than maybe you can align the top of the bottom component to the baseline of the numbers. That might be one way.

I don't think we have get text bounds in TextLayoutProxy for you to get the bounds of the area that has text (and no empty space)

I used to call this as tight text bounds that can be passed in Text as argument or in TextStyle but it isnt implemented yet

Thank you. Is there a public issue I can track for that feature?

One comment I found is here: <https://issuetracker.google.com/issues/206039942#comment6|https://issuetracker.google.com/issues/206039942#comment6>

Also in here: <https://issuetracker.google.com/issues/234274773|https://issuetracker.google.com/issues/234274773>

The second one seems to be matching more to this specific problem