Technical/stylistic advice for a table with header in the first column

English
#1

In Writer, I have some tables with headers in the first column, which in itself seems to be unsupported (am I right?).
Now, some of the tables have a large cell with some image in it, beneath the text. This makes a whole table impossible to fit on a single page. Hic sunt dragones.

I tried to reproduce simply one of the tables, and here is the first result:

image
image1166×814 71.6 KB

Then, if I fiddle with Table properties, and I mean simply enabling/disabling in ‘Text flow’ to ‘Allow table to split’ and ‘Allow row to break’ a few times, back and forth, I end up with the following result:

image
image1166×814 56.1 KB

This is the first thing I don’t understand: enabling/disabling apparently revertible settings in the dialog brings me to a non-revertible state - unless I Ctrl-Z up to the previous state.
The results in my real document are even more puzzling, as the text is broken from the image, but the incomplete cell doesn’t extend to the end of the page, like the screenshot above.

Besides my confusion, what is a possible stylistic solution when having a table breaking up this way?

The major drawback I see is that, looking at the second page alone, you have no sense of its content - no repeating header. Looking at the first page alone, you can also think that there’s no continuation on another page.

I attach here the saved documents of the two screenshots pictured.

table_column.odt (44.2 KB)

table_column2.odt (44.7 KB)

#2

You changed at least two things: table alignment (“automatic” vs. “from left”), and different number of empty paragraphs in the fourth row.

#3

Anchor the drawing As Character, not To Character. Or scale the drawing a little bit down.

#4

@mikekaganski Right, but I’ve seen that empty paragraphs in my other document have no disrupting effect, and changing table alignment back and forth, either.
I forced things a bit, with changes that apparently had no effect (alone).

#5

@Grantler what I didn’t mention is that some of the drawings have text in them; if I scale them down, they risk becoming unreadable.

#6

Usually text is not scaled down if part of a drawing. It is only if text follows shape (rarely used).

#7

My drawings are SVG/EMF/PNG; an example is flowcharts with embedded text, which becomes too small/resampled to be readable.

#8

There is presently no way to specify column headings.

IMHO, if it were possible to request column heading, this would change the semantics of a cell. In the current implementation, a cell split by page breaks remains a “single cell” where text flows from one fragment to the next. Column heading woould change this behaviour: each fragment becomes a copy of the first one and its text is repeated with its own formatting/alignment.

E.g., vertical centering alignment presently centers text in the first fragment only. In “column-heading” mode, the same text would be vertically centered in all fragments.

What happens when text is too long to fit in a fragment (for example, only a tiny row is available at bottom of page) has to be defined: truncation, removal, force row to next page to get a full-height opportunity?

As you see, there are several issues to discuss.

Back to your sample file.

You mixed frames (images) with a table. Though it will work in the majority of cases, I’d avoid it with scalable pictures with anchor other than As character. Frame interaction is specified for text only. Interaction with others objects, frames or tables, is a matter of trial and error (discovery). When you’re trying to handle page break effect, it is largely terra incognita.

First of all, I’d hand over to Writer images to be used “as is”, without scaling, cropping or anything. Second, I’d anchor these prepared images As character to guarantee that cell size will adapt in all cases. And, as always, I’d work with styles without any direct formatting (and this is very difficult on frames/images), so that changes can be made centrally and apply to all occurrences immediately.

#9

@ajlittoz I followed most of the advice; however, my real document looks different in the split row:

image
image1166×814 80 KB

I don’t know what setting/element obtained a filled row down to the end of the page in my test document. In the real one, as above, the split row is not aligned to the bottom of the page…

#10

While experimenting with your sample file (adding text in the cell containing the image), I get strange results which don’t fit in the “common” behaviour.

When a cell is split due to contents constraints (like the size of the image), the fragments, before and after the page break, become quasi-independent rows. I mean their height will be determined by the effective contents. Therefore, the fragment before the break is just tall enough to host the text (more generally contents before the break). The table will not extend down to the bottom margin, unless there is enough contents, leaving some blank space.

Thus, your screenshot is what to be expected.

However, when fiddling with your sample file, size of the fragment before the break is incorrect: it is much too tall. This reminded me of problems I had with frames in general (not necessarily inside tables) where Writer does not compute correctly what goes where and incorrectly adds frame height (or part of it) to the first fragment, resulting in too high a row or paragraph.

Anchoring As character fixes the incorrect computation. However, it is not always possible to anchor a frame As character because it could change position or document semantics and turn layout into nightmare.

So I ticked Keep inside text boundaries which allows automatic repositioning of frames (which straddle page boundaries) without changing their anchor. The row height was again fixed.

Presently, there is no automatic solution to extend a row down to bottom of page.

#11

Well, that comforts me somehow, not to be hallucinated.

And this kinds of disappoint me. The large tables are horrible, but I can’t change that format; still, I have to add large enough images to make them readable. A dog chasing its tail, I know.


Please let me add another side question here.
Whenever I open the Table properties dialog, I always have to be very careful to not select the Background tab. If I do so, the background color is selected for one of the cells I was in: if I accidentally change tab for another setting, then select OK, my whole table changes the background!
Is there any way to prevent this?

#12

Find a specific sequence that produces that, and file a bug report.

Table cells background color issue
#13

I’m not quite sure if this is a bug or rather a collateral behavior: I will describe it in a new question, to make things clear.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.