Tables and page breaks

[Bill H]

Am I the only person who looks at my DITA PDF output and says, "I sure wish I knew how to control those page breaks. Because ocassionally they look pretty bad." Especially within tables.

If I'm not mistaken, this can only be controlled by the style sheet, which I don't know how to do.

It seems pretty obvious that the DITA output to a PDF is pretty much a continuous flow from first to last page, and so you generally can't control over page breaks (although it's also obvious that the style sheet controls some breaks such as a break before a chapter start). Of course as DITA authors, we don't do formatting, but...

... what do people do?

I might add: We had a contractor who delved into XSL and made our output look pretty good, but breaks in tables are still a sore spot. Any enlightenment on this will be appreciated.

[ghkrause]

Are you able to word a rule when to add a page break?
"Ocassionally they look pretty bad" is difficult or impossible for a computer to execute.
Maybe: "Tables with more than 30 rows."

We do PDF with Framemaker. We currently discuss whether we add "newpage" in attribute otherprops of table to hardcode page breaks. But no decission, yet. Of course, if you like this idea you need to program that in XSL and XSL-FO.

[dcramer]

The DocBook xsls support soft pages breaks (i.e. a conditional page break) in the format <?dbfo-need height="2in" ?>: http://www.sagehill.net/docbookxsl/PageBreaking.html#SoftPageBreaks

Perhaps you could implement something similar or have the DITA generate DocBook and then generate pdf from the DocBook. I use DocBook and XEP and get decent page breaks by default with control of special situations when I need it.

David

[Bill H]

The "word rules" I've thought of are more like when not to break vs. when to break. For example, in some cases we merge (or straddle) table cells--if a break occurs at that point it can look pretty bad. Also, sometimes we use a header cell that spans the width of the table--if that ends up by itself at the bottom of a page it looks bad. Of course "orphan rows" where you have say, two or fewer rows by themselves on a page look bad. So somehow I'd like to see rules that would say, don't allow breaks in these instances.

A hard-coded break would not work because a table in a topic might look fine in Book A, but in Book B, with a different flow, a forced break might not look right.

[Bill H]

I just read on of Sue-Laine's posts that makes me think maybe I should be asking this in the Yahoo DITA forum. It's not really XMetaL-specific.

[Derek Read]

I agree. The types of issues you are having with tables sound to me like things you should request as improvements at the DITA OT project at SourceForge. It seems logical not to break at any of the locations you mention, ever, and there are XSL-FO settings for "keep together" that could (and should probably always) be applied here.