Allow table rows to break across pages

[TechJames]

Hello,

Is there a way to allow an individual table row to break across a page?  In other words, FrameMaker appears to, by default, keep the contents of each row together on a single page.  If the row is too large to fit on a single page, then, apparently, you're out of luck.  There must be some way to override this.

I'm working in FrameMaker 7.2.

Thanks very much.

[Art_Campbell1]

No, there's not....

You can kludge it by dividing the row into two or three or more segments -- I usually divide along paragraphs, so that each row has just one or two paras -- and use Custom Ruling to eliminate inter-row ruling, so it appears to flow seamlessly.

[TechJames]

Thanks--that makes sense.  I'm dismayed that FrameMaker can't accommodate so mundane a need.

[Art_Campbell1]

I suspect that it's a limitation imposed by the overall object-oriented design of the program -- containers inside containers (frames inside frames) nested down a large number of levels. If you few each row or cell as a container object, it makes more sense to not fragment an object.

Doesn't help us in day-to-day writing, of course, but you can see the logic and also note that the work-around complies with it.

[Guest]

Just a mildly dissenting opinion … if we're using tables to present chunks of related information in a coherent fashion, then isn't splitting a single chunk across a page-break rather against that idea? There will, of course, be cases where the chunk is relatively long; but my preference would probably be for leaving some white space and keeping the chunk together at the top of the next page.

My two penn'orth <g>

[Lynne A. Price]

… if we're using tables to presentt

>chunks of related information in a coherent fashion, then isn't splitting

>a single chunk across a page-break rather against that idea? There will,

>of course, be cases where the chunk is relatively long; but my preference

>would probably be for leaving some white space and keeping the chunk

>together at the top of the next page.

>My two penn'orth <g>

Niels,

I agree with you, and not only mildly! The point of a table is to keep

specified materialthe cells in a rownext to each other. If one cell in

a row is too tall for a page, in addition to dividing the tall cell across

multiple pages, the user may want to repeat information from other cells on

all resulting pages. Or perhaps the user may want to divide content of

other cells as well as that of the tall cell. The user may also want to

indicate where the long cell should break. Tables are very visually

oriented, and it makes sense for the user to specify the desiredresults.

--Lynne

Lynne A. Price

Text Structure Consulting, Inc.

Specializing in structured FrameMaker consulting, application development,

and training

lprice@txstruct.com http://www.txstruct.com

voice/fax: (510) 583-1505 cell phone: (510) 421-2284

[Art_Campbell1]

Well, I think we've sol9icdly entered the realm of thread drift....

But my own feeling is that if you have one cell/row with content  so deep that it fills the depth of an entire page, you have an organizational problem in your writing or information chunking. Solve that problem, and the row breaking problem disappears too.

That said, I too have had occasions when a cell just had to have to much information in it (usually due to legal requirements) and forcing the break was the only option.

ARt

[Guest]

The basic problem is technical, not legal. Our information chunking is fine - it's a chip-design industry standard - and we can't break to the next row because any script following the standard views this as "move to next engineering artifact".

And yes, we really do have table cells that will break across 2 or three pages.  And no, we can't use cross-references to point to an adjacent table because cross-refs are not in the industry standard.  Yet.

Which, no doubt, will lead to someone asking why we don't just use DITA.  The short answer is we can't.  QUALCOMM sells chips, not documents and DITA solves document problems, not chip-design problems.  In general, the Tech Writer's responsibility is to figure out how to represent engineering constraints within document confines.

You can't make chips with DITA.

David S. Blyth (UNIX and vi dinosaur)

Sr. Staff Technical Writer

QCT Division

QUALCOMM - Standard disclaimers apply

Only 149,999,949 more years of Ruling The Earth to go

[CTAS]

I agree, this should be a feature in the next update. It would save me time.

[Bob_Niland]

re: I agree, this should be a feature in the next update.

I think it unlikely to happen, but anyone asking for it needs to propose how it works:

1. The feature probably needs to be disabled by default, or it would have unintended consequences when revising existing documents within an FM that supports [enabled] row break.
2. Is it enabled cell-by-cell, row-by-row, table-by-table, document-wide, or some combination?
3. If some cells fit on the first page, are they left there, split anyway, or replicated?
4. What, if anything does the generated continuation heading and affected cell formatting do to warn the author and reader that a row break is present?
5. What if some custom ruling and shading already in use is utterly incompatible with #4?

When I've needed to do it, I use hidden borders on what are actually separate rows. Full author control.

I can see where auto-row-split would be useful when content needs to flow to page and to HTML/eBook, but some very careful specification is needed before implementation commences, otherwise it's assured to not work the way you want.

[Lynne A. Price]

Bob,

   I agree with you (and what I wrote back in 2009 in post 5 in this thread). A reliably good job of splitting tall table rows either requires a large number of options or manual processing. Your point 3 is the show stopper for me.

       --Lynnne

[Bob_Niland]

6. Because table cell text usually consists of arbitrary Paragraph Formats, which have their own Pagination properties, what sets priority when a ¶ format Pagination property contradicts a notional Row-Break property.

Due to the rise of web markup and eBook markup, any future enhancements to FM flow control need to either match or fluidly inform those workflows, and those nouveau workflows generally aren't terribly concerned about page boundaries.