Barbara Duprey wrote:
Brian Barker wrote:
I think there is a workaround of sorts. Instead of merging cells
vertically, first create a table with a single row spanning the rows
that you would have (partially) merged. Then create a new, nested
table in each of the columns in which you do not want the cells
merged, thus creating the extra rows within those columns. If you
now set the containing table not to allow rows to break, you can
sometimes get Writer to behave as you want. (This setting seems to
carry across to child tables in unclear ways.) I found that
(sometimes? always?) this didn't work if the first row happened to be
the one that needed this treatment, but I could get around this by
adding an extra row before the real first row and shrinking this to
an arbitrarily small height. I haven't tested this exhaustively, of
course, so I don't guarantee that it will work generally.
Writer doesn't split the original rows, but does split the spanning
cell (now -- it didn't in earlier versions). I'll have to play with
your workaround a bit, hadn't thought of nesting tables! But I have up
to 10 columns that have data I don't want to merge, and often 5 or
more addresses that cause these problems in the same table. That would
be a royal pain if I had to make an embedded table for each column,
and I think I'd lose the horizontal association I need when the
contents cause different row heights. But creating a single embedded
one-cell table in the merged cell sounds promising, though I might
have to specify its row height. Hmm -- maybe even without the embedded
table, but with extra blank lines, Writer would stop splitting the
cell? But maybe it will just artificially increase the height of the
first of the original rows, which would look pretty strange.
I tried the single-cell embedded table and the extra lines and neither
did any good, they didn't even force the row to the next page. (The
display got messed up, with overflow into the bottom margin of the first
page, but that's it.) The workaround Brian actually suggested would
probably work, but it isn't practical in my particular situation and the
horizontal alignment is lost if the row heights in the subtables are not
equal or forced into equality. So I'm back to my original workaround --
at least until I can really get my act together with Base reports.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
