[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [docbook-apps] HTML Column Width Trouble
|
Bob,
Thanks for looking in to this. It may not be "that" big a deal
since it looks like XHTML is going the way of the Dodo.
As a work around we just conditionalized the column specs to
only work for the PDF. Without specified widths the tables look passable in the
XHTML.
Cheers,
Eric
From: Bob Stayton [mailto:bobs@sagehill.net] Sent: Wednesday, July 08, 2009 8:39 PM To: Eric Johnson; docbook-apps Subject: Re: [docbook-apps] HTML Column Width Trouble I looked into this problem, and it appears that the
tablecolumns.extension works fine in HTML, but not in XHTML. And as far as
I can tell, the tablecolumns.extension has *never* worked for XHTML
output. If someone has experience otherwise, please let me know.
Background: the basic problem that the
tablecolumns.extension tries to address is that, according to the HTML
standards, the units for widths of HTML table columns can be only one of three
types:
- a number, which is treated as pixels
- a % value (of the table width)
- a relative value such as "2*" (which is not
universally supported in browsers).
So any CALS column widths that are specified in
units such as "cm" or "in" must be converted to pixels or they will be
misinterpreted. The extension does the math based on some assumed
conversion ratio. That is what happens when the file is processed with the
HTML stylesheet:
<col width="96">
<col width="288">
The problem with XHTML seems to be a namespace
problem. The stylesheet forms a temporary <colgroup> nodeset
that it hands off to the Java extension functions written by Norm Walsh.
When that temporary colgroup is formed in the XHTML stylesheet, it is in the
default namespace, which is the XHTML namespace that the stylesheet sets
up:
<xsl:stylesheet xmlns="http://www.w3.org/1999/xhtml"
...
It appears that the Java extension functions do not
handle elements in this namespace (not surprising if they were not written to do
so). The result is that it just copies the colgroup back without making
any changes, since it does not recognize the elements. In this case, the
values of "1in" and "3in" in the CALS table specs are passed through to the
XHTML output, where they are interpreted as 1 pixel and 3 pixels,
respectively. That forces the columns to be as narrow as possible.
The fact that some browsers actually understand "1in" and "3in" I put down to
simply being a miracle since none of the HTML standards specify such
units.
I confirmed that the namespace was the problem by stripping
the temporary colgroup of its namespace before passing it to the Java
extension. Then the extension worked properly and returned a colgroup with
widths specified in pixels. That colgroup would then need to be converted
back into the XHTML namespace before output.
The real solution is for Norm or another Java programmer to update the Java
source for the tablecolumns.extension function to work with elements in the
XHTML namespace as well as the null namespace. If I can't find someone to
do that I'll change the table templates to strip the namespace before passing it
to the extension.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]