add line height to TextFont

[Cyborus04]

Objective

• Allow users to customize the line height of text.
• Implements Let users control the line height of their text #16085

Solution

• Add a line_height field to TextFont to feed into cosmic_text's Metrics.

Testing

• Tested on my own game, and worked exactly as I wanted.
• My game is only 2D, so I only tested Text2d. Text still needs tested, but I imagine it'll work fine.
• An example is available here

---

Showcase

Click to view showcase

With font:

TextFont {
    font: /* unimportant */,
    font_size: 16.0,
    line_height: None,
    ..default()
}

With font:

TextFont {
    font: /* unimportant */,
    font_size: 16.0,
    line_height: Some(16.0),
    ..default()
}

Migration Guide

TextFont now has a line_height field. Any instantiation of TextFont that doesn't have ..default() will need to add this field.

[ickshonpe]

Is there a point to making this optional, it could just be an f32 with a default value of 1.2 instead?

[Cyborus04]

It's measured in pixels, not multiples of the font size (though that might be a better interface). Working with Options makes it simpler to implement too IMO, but changing it wouldn't be a huge deal

[ickshonpe]

Oh I see it's not a scalar. I think then it would better if there was a LineHeight enum maybe with Px and Scalar variants or something.

[Cyborus04]

I like that! Best of both worlds

[Cyborus04]

in that case, should it be a field of TextFont, or its own component? Being a separate component would make it so it's not a breaking change at all, but I'm not sure yet how to do that

[ickshonpe]

Otherwise it looks good, the UI text debug examples are still working with different line heights, don't see any problems.

[ickshonpe]

in that case, should it be a field of TextFont, or its own component? Being a separate component would make it so it's not a breaking change at all, but I'm not sure yet how to do that

The current direction atm with Bevy seems to be less granular APIs so a field on TextFont is preferable probably. A field is more discoverable than a separate component as well.

[coreh]

Nice! Left a couple comments, mostly about the LineHeight enum, but also about a potential issue with the line height math.

[coreh]

To make it easier to expand the feature set in the future (by propagating inherited line height across a hierarchy etc) without having to do a breaking change, would it make sense to have a separate LineHeight::Auto variant as the default?

[Cyborus04]

What would that do?

[BenjaminBrienen]

@coreh everything check out?

[coreh]

At a quick glance, LGTM! 👍

[Cyborus04]

do the labels need updated?

[BenjaminBrienen]

You need to fix the no-std build. It can be in final review after 2 community approvals.

[Cyborus04]

I'm not sure what I need to do to fix the nostd build, the error was in a different crate than my changes

[BenjaminBrienen]

Weird. FYI @bushrat011899

[bushrat011899]

@Cyborus04 just tested your PR locally, it'll pass the no_std checks once you update this PR to the latest changes on main. I don't have a good answer as to why you need to upstream from main, but that should fix the issue.

[Cyborus04]

I had a suspicion that's all I needed to do, I just wasn't at a computer to do so then