Image asset `w` and `h` properties

[rgprog]

For image assets, the w and h properties are not fully specified.

When w and h do not match the image's intrinsic size, existing implementations behave inconsistently:

• lottie-web resizes the image to match w and h.
• dotlottie-web (ThorVG) displays the image at its intrinsic size, ignoring w and h.

The current draft spec mentions SVG image assets, but SVG image sizing is complicated. Some SVG images have no meaningful intrinsic size. Other SVG images have a size relative to their container, like width="50%".

[mbasaglia]

I think what would make the most sense is to resize to match h / w (and for SVG to treat h and w as 100%) but that might introduce the can of worms of maintaining aspect ratio

[rgprog]

For a PNG image, lottie-web maintains aspect ratio using something like object-fit: cover.

Probably worth noting that lottie-web doesn't resample the image asset, it's just resized and cropped at the last moment during rendering.

SVG sizing has given us a lot of trouble at Jitter. I think the Lottie spec will need to avoid using language that requires image assets to have an intrinsic size or intrinsic aspect ratio (unless SVG assets are singled out as a special case?)

[mbasaglia]

Might be worth looking at how SVG handles width / height attributes for <image> and have the Lottie specs match the default behaviour.

[b-wils]

That seems like a bug that dotlottie-web ignores the w / h properties. If those are both defined they should be respected (even if it means changing aspect ratio). I'd be curious about any cases where that isn't feasible. These properties are currently required in the schema as well.

[mbasaglia]

I'd be curious about any cases where that isn't feasible. These properties are currently required in the schema as well.

As rgprog mentioned, you can have an SVG without an explicit size or the size being specified in relative units, so you don't know by how much to scale it by