Work with floating tables and positioned content

Floating tables and positioned objects are common in DOCX files created with Microsoft Word and other word processors. They’re useful for reports, proposals, invoices, contracts, and templates where a table, image, or shape needs to appear at a specific location on the page instead of moving with the surrounding paragraph text.

This guide explains how to think about floating content when building with Document Authoring and how to avoid surprises when importing or exporting layout-sensitive documents.

Inline content vs. floating content

Document Authoring supports two broad layout patterns:

• Inline content — Content participates in the normal text flow. Inline images, inline shapes, paragraphs, and regular block-level tables move as nearby text is edited.
• Floating content — Content is positioned independently of the surrounding text flow. A floating table, image, or shape can be anchored to a page, margin, column, or nearby text while being laid out at a specific position on the page. For images and shapes, users can choose wrapping modes such as square, top-and-bottom, in front of text, or behind text. Floating tables always wrap surrounding text around the table.

Use floating content when the document design needs fixed placement, text wrapping, or a Word-like layout that can’t be represented by a normal paragraph followed by a block-level table.

Use inline content when the object should behave like part of the surrounding text and naturally move as users type, delete, or reflow the document.

Floating tables

A floating table is a table positioned independently of the surrounding text. Unlike a regular table, it doesn’t simply occupy the next block-level position in the document body. This makes it better suited to layouts such as side-by-side summaries, signature blocks, form-like regions, or imported Word templates with carefully positioned tables.

When working with floating tables, keep these behaviors in mind:

• The table’s visual position can differ from its logical anchor in the document.
• Surrounding text wraps around the table. Floating tables don’t support image-style wrapping modes such as behind text or top-and-bottom wrapping.
• Text wrapping distance controls the gap between the table and nearby text.
• A floating table can still contain normal table content, including rows, cells, paragraphs, and inline content inside cells.
• Complex tables can span pages. If a floating table crosses a page boundary, layout depends on the table size, available page area, row heights, and the positioning rules imported from or exported to DOCX or RTF. When exporting to ODT, Document Authoring approximates the position with an inline table.

Use floating tables in the editor

Use the editor UI when you want a user to decide whether a table should stay inline or float with text wrapping:

1. Select the table.
2. Open the table options menu.
3. Choose Change to text wrap to convert the table to a floating table.
4. Drag the table’s move handle to reposition it on the page.
5. Choose Change to inline to convert it back to a regular inline table.

Floating tables show a move handle; dragging it repositions the table and anchors it to the dropped page position. If a floating table is split across pages, the move handle appears on the first rendered part. Tables imported from DOCX can keep paragraph-relative anchors, so the table moves when the anchor paragraph moves. If a user moves the table in Document Authoring, the editor changes the anchor to the page because the full position and anchor UI isn’t available yet.

For programmatic table creation, use regular block-level tables unless your workflow specifically requires floating layout fidelity. For more information about table content, refer to the tables guide.

Positioned images and shapes

Images and shapes can also be positioned content. This is especially common in DOCX files containing logos, stamps, callouts, text boxes, diagrams, or grouped drawings.

Positioned images and shapes may use wrapping modes such as text around the object, text above and below the object, or placement in front of or behind text. The exact behavior depends on the positioning information in the document and the SDK version you’re using.

If your app edits imported documents, treat positioned images and shapes as layout-sensitive content. Small changes to margins, section size, table size, or nearby text can affect where objects appear after reflow.

For information about reading and updating inline images and shapes, refer to the [images and shapes][] guide.

Import and export fidelity

Floating table placement and inline table alignment are preserved across supported DOCX and RTF import and export paths. ODT doesn’t have floating tables, so when you export to ODT, Document Authoring represents the table as an inline table at the closest matching position. Layout is still best effort because different renderers interpret complex positioning rules slightly differently. Document Authoring aims to preserve supported layout information, but you should still test representative customer documents before relying on a specific layout.

For example, import a DOCX file, enable users to adjust floating tables in the editor, and export the final document when they’re done:

const importedDocument = await docAuthSystem.import(file, {
  fileName: file.name,
});

const editor = await docAuthSystem.createEditor(
  document.getElementById('editor'),
  { document: importedDocument },
);

// After the user finishes editing:
const docx = await editor.currentDocument().export({ format: 'docx' });

For the best results:

• Store the working copy as DocJSON after the first import.
• Avoid repeatedly importing and exporting the same DOCX, RTF, or ODT file as your application’s internal storage format.
• Export to DOCX, RTF, or ODT when the document is ready to leave your application or when interoperability with those formats is required.
• Test exported DOCX files in the target applications your customers use, such as Microsoft Word, Google Docs, LibreOffice, or a third-party renderer.
• Pay special attention to table widths, page margins, section breaks, and text wrapping around positioned objects.

If an exported DOCX looks different in another renderer, compare it with Microsoft Word first. Some third-party DOCX renderers don’t fully match Word’s floating layout behavior.

Troubleshooting floating layout issues

If positioned content doesn’t appear where you expect, check the following:

1. Is the object inline or floating? Inline objects move with text. Floating objects use positioning and wrapping rules.
2. Is the object anchored near the expected paragraph? Floating objects often keep a logical anchor even when they’re visually placed elsewhere on the page.
3. Did the page setup change? Margins, orientation, page size, and section breaks can all change the available layout area.
4. Did the table width or cell content change? Wider tables, merged cells, long words, or changed cell padding can force a different page break.
5. Are you viewing the document in a different renderer? Renderer differences are most visible with floating tables, positioned images, grouped shapes, and text wrapping.

When you need deterministic storage and editing behavior inside your application, prefer DocJSON. When you need DOCX, RTF, or ODT interoperability, validate the final exported document with the applications your customers use.

Learn more

Sections and page setup
Control page size, orientation, and margins per section.

Tables
Build, read, and update table content.

Images and shapes
Find, resize, and restyle inline images and shapes.

Import documents
Open DOCX and other formats in Document Authoring.

Export documents
Export documents to DOCX, PDF, and other formats.