[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] DocBook/XSL/FO-HTML and Table Column Widths
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]