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?

Thanks

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
b...@sagehill.net


----- Original Message ----- From: "Tom Browder" <tom.brow...@gmail.com>
To: <docbook-apps@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.

Thanks,

-Tom

Thomas M. Browder, Jr.
Niceville, Florida
USA

---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org





---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org


--

------------

Steve Johnson, Senior Content Developer
Caringo
ste...@caringo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-apps-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-h...@lists.oasis-open.org

Reply via email to