(EDIT: I added an other point to care about in the difficulties with frames; so, take a look if you have already read this post)
First of all, Writer is intended to process text. Text is defined as a continuous flow of characters. For a reason becoming obvious later, your topic text is called main flow. This main flow extends from beginning of document to end and is split into pages by the process.
As you know, this monotonous sequential layout is not what you find in common documents. Authors frequently want to highlight some point through footnotes or margin notes and illustrate the topic with images or charts. I leave aside footnotes because they are “easily” handled by geometric considerations related to page dimensions. The main issue with the other “highlights” is interaction with text, more precisely preventing overlay between main text and the “addition”.
This is the role of frames. A frame “punches” a hole in the page to remove this area from the arena available to text. A frame creates a secondary flow. By all aspects, frame contents becomes an “independent” sub-document within your document with all features enabled, just like in the main flow. There are however two limitations:
- a frame size is limited to the page dimension and no extra frame will be automatically allocated in case contents overflows (contrary to pages in the main flow)
This limitation can be mitigated if you create manually new frames in subsequent pages and link them explicitly. Use this with parsimony. If you rely extensively on this feature, Writer is probably not your required tool; look at DTP (desktop publishing) applications like Scribus.
- frame size automatically adjusts to text only
You can nest a frame inside another frame but this nesting is visual only. Frame properties cannot be made dependent on another frame. If the “inner” frames grows, the “outer” frame does not change. The position of the “inner” frame can have a different reference than the “outer” frame and moving the “outer” frame has then no impact on the “inner” one.
The union of areas covered by frames is removed from any text estate, be it for the main flow or secondary flows in the frames.
Images create “special” frames on insertion. For ease of management, the image bounding rectangle is converted to a reduced version of a frame when the image is added to the document. “Reduced” here means that this frame cannot contain text of its own. Only the image is contained in the frame.
As I mentioned earlier, the primary goal of frames is to remove an area from the usable surface in the page forcing (principally) the main flow to be set around these blind spots. Frames impact text layout algorithm. It is important to note that you can’t specify frame-frame behaviour constraints (except one, but not sophisticated enough to cover all author’s requirements). This is what makes difficult reliable automated relocation of frames when they conflict.
An example of this is the creation of a caption. The built-in feature “cheats”. It creates a frame around the caption paragraph (we then have a standard text frame), attaches (or anchors) the image to the caption paragraph with a position constraint relative to the paragraph and computes a frame size large enough to contain both the caption paragraph and the image. But if you replace later the image by another one with a different size, it is very likely that the caption frame size is wrong (too small or too large, possibly the image completely offset). And worst of all, a caption frame is direct formatted (by internal macros). See below the consequences.
Frames are controlled by frame styles. But these frame styles are very hard to master because
- wording used in naming the parameters is not optimal, confusing newcomers
- people don’t understand the difference between anchor and position
Don’t use To page anchor until you understand this non-obvious option. All other anchors (except As character of course) allow you to send the frame anywhere in the page.
- there is no ordering between frames when scanning
There is no problem with rendering because it is done sequentially from first page to last page; Visually, everything is as expected, notably numbering (chapters, lists, number ranges used in captions, …). But scanning to collect data, e.g. creation of TOC, is done following internal pointers, just as they are met. There is no ordering relation between internal storage and visual rendering. Consequently, if you used frames to achieve fancy positioning of chapter headings, you may end up with a messed TOC. Keep data related to a flow inside this flow!
- frames are extremely sensitive to direct formatting (much more than text)
Any suspicion of direct formatting (DF) on a frame is enough to mask completely the style, even on settings not related to the DF, and this DF is next to impossible to clear.
DF on frame is as “innocent” as moving the frame or changing its size with the mouse! If you want predictable behaviour, always modify the style. Never use your mouse or keyboard arrows.
For an obscure reason(+), drawing objects (shapes, text boxes, curves, …) don’t give birth to a special form of frame like images do. Consequently, they aren’t controlled by styles. They are handled individually with direct formatting. This will make it difficult to maintain synchronism with text.
I’m thinking in particular of arrows used to connect a word with some other word or image. A drawing object can be anchored to a single character while an arrow needs two: source and destination.
(+)A possible explanation can be that a useful drawing is composed of several shapes and Writer cannot guess if these shapes on a page are members of a single drawing or should be split into several ones. Anyway, creating one frame per shape is certainly the worst solution considering the lack of logic on this approach and its impact on performance.
Considering that drawing object management is rather primitive in Writer, I recommend you design your illustrations in Draw because it is easier, more commands are available and, most important, you don’t disturb or damage your text while working. You the copy the part you’re interested in and paste it into Writer. Implicitly, all objects you copy are grouped into a single “block” you can manage easily in Writer (positioning is done on the block, not on individual components).
For repositioning automation, you can insert a frame, anchor the drawing to the default paragraph in the frame and adjust the frame size. This is very similar to the Insert>Caption command. After that, your drawing is indirectly controlled by a frame style.
