Cannot determine image width/height for external images, results in NaN

[figure002]

Expected Behavior

Given an external image with a scale set:

<image scale="15" href="https://i.imgflip.com/21r054.jpg" scope="external"></image>

I should get the following HTML output:

<img class="image" src="https://i.imgflip.com/21r054.jpg" height="69" width="93">

Actual Behavior

Both the height and width are set to "NaN":

<img class="image" src="https://i.imgflip.com/21r054.jpg" height="NaN" width="NaN">

Steps to Reproduce

See code examples above.

Copy of the error message, log file or stack trace

I noticed in the dita output with --verbose that there don't appear any log messages about fetching image metadata when I set an external image:

html5.image-metadata:

But if I change the src attribute for one image tag <image> to a local image, I do get log messages about fetching image metadata:

html5.image-metadata:
[image-metadata] Processing /tmp/temp20240130160843626/html/topics/9.dita
[image-metadata] Processing /tmp/temp20240130160843626/html/topics/11.dita
[image-metadata] Processing /tmp/temp20240130160843626/html/topics/2.dita
[image-metadata] Processing /tmp/temp20240130160843626/html/topics/6.dita
[image-metadata] Processing /tmp/temp20240130160843626/html/topics/5.dita
[image-metadata] Processing /tmp/temp20240130160843626/html/topics/3.dita
[image-metadata] Processing /tmp/temp20240130160843626/html/topics/8.dita
[image-metadata] Processing /tmp/temp20240130160843626/html/topics/1.dita
[image-metadata] Processing /tmp/temp20240130160843626/html/topics/10.dita
[image-metadata] Processing /tmp/temp20240130160843626/html/topics/7.dita
[image-metadata] Processing /tmp/temp20240130160843626/html/topics/4.dita
[image-metadata] Reading file:/srv/dita/out/0d5659a6-f83e-469c-bf25-55c840ce5125/topics/images/21r054.jpg

So it appears that the image metadata fetching code is not executed when it should be.

Environment

• DITA-OT version: 4.1.2
• Operating system and version: Linux
• How did you run DITA-OT? dita command
• Transformation type: HTML5

[jelovirt]

This will probably be fixed by a fix to #4356

[figure002]

Thanks for the reply @jelovirt. Is anyone working on a fix already?