On Thursday 24 January 2008 11:24:56 Barbara Duprey wrote: > 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?
Just out of curiosity, why are you not using Base for this? It seems to me that a form with a subform would work. Queries and Reports would then provide access to this data. Dan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
