images.convertToInline() converts floating images to inline but preserves the original paragraph anchor, resulting in incorrect layout

[vbg-med]

What happened?

What happened?

When converting floating images using editor.doc.images.convertToInline(), the API reports success and the image's placement changes from floating to inline.

However, the resulting layout does not match the expected inline flow.

Expected

A floating image converted to inline should appear as a normal inline image in the document flow, for example:

Paragraph A

[Image]

Paragraph B

or otherwise preserve Word's visual reading order.

Actual

The image is inserted into its original anchor paragraph, causing surrounding text to flow beside the image.

For example:

data data: Normal...

[Image]data data datas...

Right data data...

instead of

dat data dat: Normal...

[Image]

data data data data ...

Right datadata...

The API returns:

{
"success": true,
"image": {
"kind": "inline",
"nodeType": "image",
"nodeId": "...",
"placement": "inline"
}
}

and images.list() confirms the image placement is now "inline".

So the conversion succeeds, but the resulting layout is unexpected.

Steps to reproduce

Steps to reproduce
Open a DOCX containing floating images with square text wrapping.
Call:
const { items } = editor.doc.images.list();

for (const img of items) {
editor.doc.images.convertToInline({
imageId: img.sdImageId,
});
}
Observe the rendered document.

The image becomes inline but remains embedded in its original anchor paragraph, causing text to wrap beside it instead of appearing before and after the image.

SuperDoc version

1.43.2

Browser

Chrome

Additional context

Additional context

The image metadata before conversion is:

{
"properties": {
"placement": "floating",
"wrap": {
"type": "Square"
}
}
}

After conversion:

{
"success": true,
"image": {
"placement": "inline"
}
}

[linear-code]

IT-1291

[vbg-med]

Workaround attempted

I also attempted a workaround instead of using images.convertToInline().

Workflow

1. Enumerate all floating images using editor.doc.images.list().
2. Save each image's metadata (sdImageId, anchor.blockId, src, size, alt).
3. Resolve the image's anchor to a BlockNodeAddress using editor.doc.query.match(...).
4. Delete the floating image using editor.doc.images.delete(...).
5. Recreate it as an inline image using editor.doc.create.image(...) with at: { kind: "after", target: address }.

Results

The workaround was not successful for two reasons:

1. All recreated images were inserted near the start of the document instead of their original locations.

   Although each image had a different anchor.blockId, both resolved to the same BlockNodeAddress:

   Image 1
   anchor.blockId = e01a7610-...
   resolved address = { kind: "block", nodeType: "paragraph", nodeId: "4E6FF1B3" }
   
   Image 2
   anchor.blockId = 47486208-...
   resolved address = { kind: "block", nodeType: "paragraph", nodeId: "4E6FF1B3" }
   

   As a result, both images were recreated at the same paragraph near the beginning of the document.

2. Image appearance was not preserved.

   The recreated images lost aspects of their original formatting, including sizing/cropping. Since create.image() only accepts src, size, alt, and title, it does not preserve floating-image properties such as wrapping, transforms, cropping, offsets, or other placement metadata.

Questions

• Is there a supported way to resolve an image's anchor.blockId to the correct BlockNodeAddress for mutations such as create.image()?
• Is there a recommended way to recreate a floating image as an inline image while preserving its visual position and dimensions?
• Should images.convertToInline() preserve the visual reading order (for example, by placing the resulting inline image between the surrounding paragraphs rather than embedding it within the anchor paragraph)?