OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dita-comment] Table breaks - Request for better control capability


William;

 

I think that your question might be better addressed to the DITA Users group (http://tech.groups.yahoo.com/group/dita-users/), as I recall several discussions there regarding such issues. This email list is intended more for public comment on the DITA specification, which by definition tries to stay away from proscribing output processing rules.

 

That said, I also recall some discussion (perhaps in the DITA Adoption TC) about creating some baseline “best practices” for processing instructions to handle some formatting issues. If such quasi-standards aren’t put in place somewhere, then different tool vendors will come up with their own methods, and we’ll end up with divergence in the community. Perhaps someone else monitoring this list will recall the outcome of those discussions and point us in the right direction.

 

Respectfully,

Bob Beims

Chair, DITA TC Semiconductor Information Design Subcommittee

 

 

From: William Hagen [mailto:William.Hagen@hughes.com]
Sent: Tuesday, January 06, 2009 2:36 PM
To: dita-comment@lists.oasis-open.org
Subject: [dita-comment] Table breaks - Request for better control capability

 

This is a combined question and request:

 

Are there ways DITA and/or the OT could be improved to improve table/page breaks in PDF output or provide options for this? It seems the usual answer is to modify your XSL-FO settings, but I think most DITA users don't know how to do this. So I wonder if there's a way to fix "bad" table/page breaks in all cases (or easy options to control break behavior).

 

Examples of bad page breaks:

 

If a break occurs where table cells have been merged (or straddled), the result can look pretty bad.

 

Sometimes a cell that spans the width of the table is used as a header to divide main parts of the table--if that header ends up by itself at the bottom of a page it looks bad.

 

"Orphan rows" where you have just one or two rows by themselves on a page look bad.

 

Comment: It seems that "hard-coded" breaks in a table would not be a good solution, because the break might look fine in Book A, but in Book B, with a different flow, the forced break might not look right.

 

There's a lot I don't understand about this problem, but I know that page breaks within tables are the biggest visual/layout problem in my DITA documents. Is there a way to address this other than just saying "fix it in your stylesheets"?

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]