Inline and Floating Objects in MS Word

We are all used to working a lot with tables when designing report templates. The topic of this article is one of the most important object formatting settings that is often overlooked: the difference between an Inline object and a Floating object.

There are several different MS Word objects that can be made floating: Shapes, Pictures, Tables and Charts. The same logic of formatting rules applies to all of them, but in this article, we will focus on tables primarily.

Each new object that you insert directly in a Word document body is initially placed as an Inline object. However, this setting often automatically changes to Floating when you drag and drop an object.

Of course, there is nothing wrong with this handy Word feature. After all, we are all used to the drag and drop functionality, but it is good to know that the change of this important setting is done without notifying the user. This is the main reason why this setting is so easily overlooked, but it can have a significant impact on your document’s layout.

You can check the status of this setting if you right-click on a table, then open Table properties > Table Options and check the Text wrapping setting. Every object is formatted either as an Inline object (Text wrapping = None) or as a Floating object (Text wrapping = Around).

Let us take a look at some of the practical consequences of this setting for the template designs and some possible cases.

A floating object cannot break across multiple pages

Imagine a case where an object would be rendered on more than one page. In an inline-formatted table with several invoice lines, for example, a break would be inserted at the point where the table rows reach the bottom page margin. The rest of the table rows would continue on the next page.

On the other hand, if our table is formatted as a floating object and its rows will not fit on a single page, it will not behave in the same way. Such a floating table will simply not be split and will render on the same page even though there is not enough space.

With the setting changed to Around, our floating table now extends beyond the end of the page, not respecting page size or margins. Part of the data of our report, which we wanted to print on the next page, is thus apparently "lost ". In fact, this is only the result of the floating object formatting.

Positioning of the tables in the template

When you are dealing with tables that should appear one after another in your report, it is best to avoid formatting the tables as floating objects.

We have already encountered some cases where the objects from the template seemingly switched positions. Consider an example where the tables (highlighted in blue, green, and orange) change places as the report is printed:

The reason behind that is precisely the fact that some of these tables were formatted as floating objects. When our report is rendered, all the objects from the template follow numerous layout settings regarding their size, position, text wrapping and anchoring options.

At run-time, when dynamic report data replaces tagging elements and the final report document is generated, table rows in List tagging elements will multiply and a change of size of these objects is likely to happen. The resulting tables in the generated document can have considerably different size compared to the template tables. Additionally, Group tagging elements might multiply, while If tagging elements might hide table rows. All these changes to the newly rendered Floating objects affect their final relative positions in the document.

On the other hand, Inline tables and objects follow the main content flow. By making tables inline we make sure the resulting tables in the generated document are all rendered in the right order, just as one would expect.

Conclusion: When working with report templates, use inline tables and shapes whenever possible. Use floating objects only when a layout requirement cannot be achieved with inline objects. If it is possible to implement the desired design in this way, the resulting layout is always more predictable.

See also

Last page footer >>