
Some parts of this message have been removed.
Learn more about Nabble's
security policy.
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
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.
----- Original Message -----
Sent: Wednesday, July 08, 2009 1:05
PM
Subject: RE: [docbook-apps] HTML Column
Width Trouble
As a side note to this issue, Webkit (Safari and Chrome at
least) based browsers do not seem to have a problem with the generated HTML
output. Firefox and IE8 are unhappy with the HTML output
however.
Hi Eric,
When you say the "HTML does not come out right",
can you be more specific? Can you show what the XML input is and the
HTML output is?
Also, what version of the stylesheets are you
using?
----- Original Message -----
Sent: Thursday, July 02, 2009 3:28
PM
Subject: [docbook-apps] HTML Column
Width Trouble
When I set the colwidth for a CALS table the
generated HTML does not come out right.
I'm using Saxon 6.5.5 and have the extensions
turned on (and on the classpath). The graphics extension is working fine, so
I'm pretty sure they are set up properly.
Is there something I'm missing?