[Redy144]

What/Why?

Fixes #1083. An inline image (![alt](url) after text) looked different on each platform. iOS and web stretched a non-square image to fill the inlineImage.size square. iOS also missed the cap height, more so the larger the image, and web centred on vertical-align: middle, below the capitals. Android already fitted the image inside the square and centred it on the cap height (#1089).

Every platform now fits the image inside the square, keeping its proportions, and centres it on the cap height of the text around it. The issue suggested filling the square (cover). This PR uses contain instead, so nothing is ever cropped. That's what Android already did, and what chat apps with a fixed emoji-sized square do, Discord for one.

• iOS (React Native and native): inline images draw with contain / .fit. The offset uses the font of the text around the image, bold and italic included. On native iOS a paragraph lineHeight moves the image together with the text.
• Web: object-fit: contain and vertical-align: calc(0.5cap - size / 2), falling back to middle where the cap unit isn't supported (Safari before 17.2).
• Android (enriched-markdown-android): image.borderRadius was converted to pixels twice, so a rounded 20 dp inline image came out as a circle.
• Docs describe the square and the centring.

Testing

Open Storybook › EnrichedMarkdownText › Inline › Inline Image › Non Square in the example app. It shows wide, tall, square, 10:1 and 1:10 images at inlineImage.size: 48. The web screenshots are the same Markdown in the web example.

	Before	After
iOS
Web

Android didn't change, and now matches iOS:

Android

• New tests: InlineImagePlacementTests (native iOS, measures painted pixels), ENRMInlineImagePlacementTests (React Native iOS), inlineImageStyle.test.ts (web), and ImageCornerRadiusTest plus a wide image case in InlineImagePlacementTest (Android).
• Passing: native iOS (742 tests), React Native iOS (72), web Jest (1625), and testDebugUnitTest with ktlintCheck in both Android packages.
• Maestro: regenerated the inline_image_display baselines (Android, iOS, native iOS). I haven't run the full suite.

PR Checklist

• Code compiles and runs on iOS
• Code compiles and runs on Android
• Updated documentation/README if applicable
• Ran example app to verify changes
• E2E tests are passing, only inline_image_display was run
• Required E2E tests have been added (if applicable)

[maksg]

Looks solid! 💯

Left just one small comment

[maksg]

Both cases pass @"" for strongFontFamily:, so nothing tests the bold path or ENRMImageAttachmentsAdoptTextFonts: the suite still passes with that call removed. A **…** case in this loop wouldn't catch it either, because Georgia's cap height is too close to the system font's (the centre moves 0.1pt, the tolerance is 0.5).

A direct check does:

- (void)testInlineImageTakesTheFontOfStrongText
{
  ENRMImageAttachment *image = nil;
  NSUInteger index = 0;
  NSTextStorage *storage = [self render:@"**HH {image} HH**"
                              imageSize:CGSizeMake(32, 32)
                       strongFontFamily:@"Georgia"
                                  image:&image
                                  index:&index];
  UIFont *textFont = [storage attribute:NSFontAttributeName atIndex:index + 2 effectiveRange:NULL];

  XCTAssertEqualObjects(textFont.familyName, @"Georgia");
  XCTAssertEqualObjects(image.textFont, textFont);
}

It fails without the ENRMImageAttachmentsAdoptTextFonts(output) call. The @"" entries and the ternary in this loop can then go.

[hryhoriiK97]

LGTM! Thank you for the fix!