A Prototype for Dynamic Text Flow - An Overview

In this post I describe part of my project for GSoC 2014: automatic flow of text from one box to another in Draw/Impress. I outline some of the current features and limitations and describe future developments.

An Overview of Dynamic Text Flow

Imagine having a text box containing too much content for its size. In some documents it is not possible or convenient to solve the problem resizing the box or the font. In these situations we may want the overflowing text to move to some other area in the document, such as another text box logically linked to the overflowing one.

To have a concrete idea of the kind of behavior we expect, look at the following screenshots from one of the latest versions of the prototype (written during GSoC 2014).
When the user enters too much text for a single box this is automatically distributed among the others until it fits (or until there are no more boxes to fill). Notice that (currently) the text is redistribited paragraph-wise: each box receives as many paragraphs as it can contain - in this case one per box. Also notice that the rightmost box in the second screenshot is filled because the second and third paragraphs, once moved from the leftmost box, do not fit completely in the central text box; thus chaining occurs recursively.

While the user is still editing the content is shown as overflowing.

The text distributes itself automatically after editing.

A more desirable behavior: beyond the tiranny of paragraphs and "editing mode"

The screenshots above give an idea of what the current prototype does, let us now look at some of possible improvements. There are two major flaws in the current implementation:

  • text cannot be broken at arbitrary locations, only at the end of paragraphs;
  • user has to stop editing to see results.

We would like that text could be automatically moved anywhere between two words, not only between paragraphs. Also we would like such "automatic transfer" to occur seamlessly in real time (Writer, for example, implements such behavior), not only after editing is done. This is a serious problem both because it reduces the WYIWYG-ness for the user (who has to stop and check her results every once in a while) and because it complicates the design of the feature increasing the number of questions to be answered; all these questions hardly have a sensible answer from a UX point of view: should the whole text appear only in the first box (as it is the case now)? If yes, then shouldn't the next logical boxes be special and should not be editable?

The main goal of my GSoC 2015 project is to achieve the two properties above. As a starting point on deciding how to build them, I will now get back to the current implementation describing what it does under the hood.

Current prototype: a skeleton

The following is a overall scheme of how the current implementation works. The reader will notice how the general idea is extremely simple.

When user is editing: keep track of whether (and at which paragraph) the text exceeds the box size.

When user is done with editing: when creating "non-edit-mode" text of the box, if overflows occurred:

  • "cut" the overflowing paragraphs from text in current box;
  • set the overflowing paragraphs as text in the next logical box and recursively call checks on overflows.


The current prototype for text chaining should be modified to handle between-words breaks and real-time modifications. Going in this direction will require abandoning a good part of code written last year (or at least the approach outlined above).
Next steps:

  • finding out how to test for overflow by words only; currently complete paragraphs are used to test for overflowing content.
  • finding out how to possibly modify content of text boxes in real time; current code depends completely on the user exiting editing mode.