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
>
bobs@sagehill.net>
>
> ----- Original Message ----- From: "Tom Browder" <
tom.browder@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-unsubscribe@lists.oasis-open.org>> For additional commands, e-mail:
docbook-apps-help@lists.oasis-open.org>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
docbook-apps-unsubscribe@lists.oasis-open.org> For additional commands, e-mail:
docbook-apps-help@lists.oasis-open.org>
--
------------
Steve Johnson, Senior Content Developer
Caringo
stevej@caringo.com