InlineImage custom size and flipping support

[ickshonpe]

Objective

Add support for custom sizing and flipping to InlineImage.

Solution

New fields width, height, flip_x, flip_y on IinlineImage.

Preserves the image's aspect ratio if dimensions unset.

---

Probably the dimensions should be Vals but the implementation needs a bit of thinking about, so left it for a follow up

Testing

Includes new test resolve_inline_box_size.

Updated the inline_image example and inlineimage ui testbed scene.

[github-actions]

Your PR caused a change in the graphical output of an example or rendering test. This might be intentional, but it could also mean that something broke!
You can review it at https://pixel-eagle.com/project/B04F67C0-C054-4A6F-92EC-F599FEC2FD1D?filter=PR-25767

If it's expected, please add the M-Deliberate-Rendering-Change label.

If this change seems unrelated to your PR, you can consider updating your PR to target the latest main branch, either by rebasing or merging main into it.

[viridia]

Fine for now, but I assume we eventually want these to be Val units. (Particularly Em/Rem).

[ickshonpe]

Fine for now, but I assume we eventually want these to be Val units. (Particularly Em/Rem).

Yep I left Vals for a follow up as I wasn't quite sure what to do some of the variants:

• Em: which Em, the root's, parent's, or one of the adjacent sibling text sections'?
• Percent would need to based on something, can't be the size of the text node or line height as it would be cyclic. If it's Em same problem as for Em above. Could be based on image size or Rem size but neither seems natural?

Could use FontSize instead of Val, as it has no Percent variant. But setting an image size using FontSize seems weird too.
It may just be a case where there's no happy solution, just have to pick the least worst option and highlight the weird parts in the docs.

[viridia]

• Em: which Em, the root's, parent's, or one of the adjacent sibling text sections'?

It doesn't really matter; root is probably easier and more consistent.

The practical use case is: "I want an icon that is 20% larger than the text height of the paragraph it's embedded in". Having a paragraph contained mixed sizes is rare; generally font size applies to an entire heading or caption.

[KaytonFletcher]

Probably dumb question but is zero a valid/possible image size here?

[ickshonpe]

No that's a reasonable question. I don't think this function should do any validation, that should be left up to the caller. Instead, I added some extra logic to the update_inline_image_boxes system that sets the InlineBox to zero if the resolved box size is invalid. IIRC it's not strictly necessary, images shouldn't be zero-sized and Parley will ignore any invalid values, but it seems okay as a low cost defensive measure.

[KaytonFletcher]

Just for my learning what's the easiest way to see the new examples on an open PR? Not sure if screenshots in PR desc. are common practice to make it easier for reviewers.

[ickshonpe]

Sometimes I add screenshots, but they can be a bit unreliable. It's much better if reviewers run the examples and check that they work for themselves. I've had a couple of PRs where the changes were fine on my computer, but on other platforms there were graphical artifacts.

The examples here can be run with:

cargo run --example inline_image

cargo run --example testbed_ui -- inlineimage

[ickshonpe]

• Em: which Em, the root's, parent's, or one of the adjacent sibling text sections'?

It doesn't really matter; root is probably easier and more consistent.

The practical use case is: "I want an icon that is 20% larger than the text height of the paragraph it's embedded in". Having a paragraph contained mixed sizes is rare; generally font size applies to an entire heading or caption.

Yeah I think I agree, we can just simplify things by assuming a uniform line height (taken from the root text section). I was thinking about how to implement automatic sizing that would adjust the image size to best fit the text layout, but it's not worth the effort for something very niche, however unsatisfying the alternative is.

I'll still leave it for a follow up, as this is very simple and an obvious merge.