Barbara Duprey wrote:
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.
Bug report filed: http://www.openoffice.org/issues/show_bug.cgi?id=85605
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
