Brian Barker wrote:
At 19:15 23/01/2008 -0600, Barbara Duprey wrote:
I've asked before, but no answers yet, so I'm trying again. Do other
people think it's a bug that cells of a complex row (with cells
merged, vertically in this case) can split across pages when the
table properties say that rows are not to be split? This just started
happening recently, I think in version 2.3, and I haven't found an
acceptable workaround. This definitely gets in my way very regularly,
the process I used to use is now broken.
For the benefit of someone who asked for an example, here is my
explanation of the problem. Suppose you create a table with more then
one column and more than one row. Then you merge two or more cells
vertically in one or more columns. So far, so good. Now you remove
the default tick from "Allow row to break across pages and columns",
with the intention of keeping each cell unbroken on one page or
another. The problem is that Writer, whilst keeping the original
cells intact, appears to maintain what is effectively a hidden
boundary between the merged cells and - unhelpfully - to allow the
merged cell to break across pages at this boundary.
Yes: if it prevents you doing what is intuitive and what you need, it
probably is a bug.
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.
I trust this helps.
Brian Barker
Thanks, Brian -- yes, that's what causes the problem. Just to make it
easier for everybody to visualize: each of the original rows has a
number of columns with related data pertaining to a particular house
address, but the same address can be referenced in multiple rows. These
rows are physically contiguous, and the street name is the first column
of the table. I've been merging the street name cells, retaining a
single copy of the address data, to keep everything about the same house
address on the same page. That's what is broken now. And since the
street name fits on a single output line (as is), it's irrelevant to the
page boundary issue.
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. Anyway, either way would be a more
robust workaround than what I've been doing (splitting the table at the
first of the problematic merged rows, and inserting a hard page break if
necessary). It would at least respond better to other changes. Or I can
just give up and let the new page start where it wants, but with a blank
address to make it clear what's going on -- though that gets me back to
the original problem I was trying to solve. Some of the people using the
tables are physically going to the addresses and checking the data, and
it's easy for them to be past the house before they realize there's more
to look at.
Time to write up a bug report, too, I guess.
I also need to spend some time looking at the new report generation
capabilities from Base, with forms and subforms, to see if it can now do
what I need -- all my data is derived from Base, with each original
table row coming from a single record in an HSQLdb embedded database,
and it would be great if I could skip all this manual stuff completely.
Looking at it under 2.0.4, I couldn't find a way, but maybe now?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
