Often, in the books we do, we have to separate some text from the main flow, but still keeping it in the flow. This could be facts, side stories – what I usually would call box texts.

In a design, there are many ways to separate special text from the main text. If the book is set with a serif typeface, you could do the special text with a sans, or you could change the color of the text etc. But many times you want to put the text in a box, so you can change the background color behind the text, or you can make a border around it.

The way I currently do it, is I am placing the text in a table with one row and one column. This way I can control the background color, border, padding and distance to the text before and after the table. But the weak point of this solution, is that you cannot "break a table" across a page or column. If the table is to high to fit, it will just be placed in the next column. This leaves you to split the table manually in two rows, where the table should break.

Another way to "fake a box look" by adding a background color, is to use the paragraphs underline, strikethrough, or rule above and below functions. The way you do it, is by defining a rule or line that is about as thick as the leading and adjust its offset to match the wished effect.

An example of the three mentioned ways of adding "inline boxes" in a text flow.

Inline box != table or text frame

Using tables you can make the box have a border. Using underlines or strikethroughs, you can make the box break automatically after columns, but the background color will be only as wide as the single lines. Using paragraph rules, your box may not be more than two text lines, since the rules only applies to the first and last line of the paragraph, but it also gives you the ability to adjust a horizontal offset for the background that extends the text frame they are in.

Some might suggest you use inline text frames, but as with images they only wrap text below them. So if you wish to use text frames, to e.g. round the corners, add a shadow etc. you will be best off by putting that frame inside a table, because tables always wrap text both above and below.

So Adobe, my wish: Let us have a background color and border option for paragraphs, or add a new form of inline box.

Comments

Nathan Jones wrote:

Interesting method… I find the tables clunky and only use them for a data display - say, bringing in data from an excel spreadsheet that needs to be displayed in a table.

You can be very creative with footnote styles too. This will keep your 'aside' text linked to a certain point in the main text, but show as boxed out. This is handy if the main text is still being edited whilst the design is being laid out.

Personally, I prefer the text to be as polished as possible to save design time and use simple text boxes with a style sheet. It seems the quickest way.

Always fascinating to hear how other people approach these things, though!

Silkjaer wrote:

Thank you for your comment.

By footnote styles, do you mean anchored objects?

The only reason I often use tables for boxes, is that it wraps text both above and below the text flow. Which also can be a smart way to place photos/illustrations - inside a table. Or do you know a way to make inline images and text frames wrap text above?

Per Ljunghall wrote:

What does "wrap above" mean? My InDesinglish is quite poor.

Silkjaer wrote:

By writing "wrap above" I mean that the table will not be placed on a text baseline and grow up "into" the text above but "wrap it".

Try placing an image in a text and and then a table. An inline image/text frame will grow into the lines above the baseline it in.

Per Ljunghall wrote:

Hm, then my english isnt't that bad after all. I use anchored objects to do exactly what you do, but I drag the box down as much as it takes to make it wrap as much as needed. There must be a way to calculate how much is needed from time to time.
http://ljunghall.nu/silkjaer/anchored-wrap.png
Or am I missing something here...?

Silkjaer wrote:

I use a single celled table instead to avoid the downshifting - but I'm sure it is mainly just a question of routines :)

Per Ljunghall wrote:

Yes, tables *are* "clunky" in a newspaper design.

Write a comment!