|Subject:||Re: [docbook-apps] DocBook/XSL/FO-HTML and Table Column Widths|
|From:||Steve Johnson (ste...@caringo.com)|
|Date:||Jul 18, 2010 9:39:41 am|
Off the subject but is there a way to stop FO from breaking a row in the middle? IOW, to push an entire row to the next page?
On 7/18/2010 11:03 AM, Bob Stayton wrote:
Hi Tom, First question: was there any column width information in the HTML tables from which you converted that content? If so, ensuring that the conversion included the column widths would likely help.
The column widths stylesheet extension is not going to help you if your tables have no column width information. The extension just converts potentially complex CALS colwidth values to simpler HTML values. If there is no column width information to work with, it will just give each column the same percentage width. The extension has no means of measuring the widths of typeset columns, because the columns have not yet been typeset.
If your HTML tables did not have column width information, then the browser was choosing how wide to make each column based on the column content. A similar function is available in XSL-FO in the table-layout="auto" property on the fo:table element. That engages a formatting algorithm in the XSL-FO processor that reads the width of the typeset content in the columns and adjusts the column widths for a better fit. It works best with short entries that don't have to wrap lines.
But I believe you said you were using FOP, and FOP does not currently support the table-layout="auto" property. You would need to use another FO processor.
Bob Stayton Sagehill Enterprises bo...@sagehill.net
----- Original Message ----- From: "Tom Browder" <tom....@gmail.com> To: <docb...@lists.oasis-open.org> Sent: Sunday, July 18, 2010 8:05 AM Subject: [docbook-apps] DocBook/XSL/FO-HTML and Table Column Widths
I have pretty much converted an old, large html-based set of docs into DocBook 5. The only chunk I'm not happy with are the tables which need customizing to adjust column widths.
Adjusting the column widths seems problematic at the moment for one using xsltproc. I see that Norm Walsh has a Python wrapper to take care of that (and I'll explore that soon), but that seems to add another layer to the tool chain that is already daunting for a newbie.
My questions are:
1. Where should the necessary missing functions and algorithms be inserted, into xsltproc, or?
2. Are the table column formatting functions really extensions, or should they be considered part of a core standard that is missing in xsltproc and other xsl programs?
I would like to offer my help for the situation but am not sure where to start.
Thomas M. Browder, Jr. Niceville, Florida USA
Steve Johnson, Senior Content Developer Caringo ste...@caringo.com