Excellent, David. I will look at that option. I managed to get rid of all the other old code, but this little enigma had me baffled.
Bill Burns Verbum Communications, Inc. +1.208.336.6081 [email protected] http://www.verbumcomm.com -----Original Message----- From: David Cramer [mailto:[email protected]] Sent: Monday, August 01, 2011 5:30 PM To: [email protected] Subject: Re: [docbook-apps] Odd column resizing issue -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Bill, I assume you are able to add steps to their build process if you're adding the indexing step, so you could run their html output through some version of tidy [1] to turn it into xhtml before running the webhelp indexer on it. That way you wouldn't have to touch their ancient xslts. Regards, David [1] http://en.wikipedia.org/wiki/HTML_Tidy On 08/01/2011 06:12 PM, Bill Burns wrote: >> I'm sorry, but it is a little hard to understand what you are doing. >> May I ask why you need to retrofit webhelpindexer to work with a very old >> version of DocBook-XSL? > >> I don't know how to reproduce the table columns problem. You mention >> the adjustColumnWidth extension function from docbook.py in your follow-up >> post, so I presume that you use Python to do the transformation. Is this >> right? > > The client I'm working for developed their own flavor of Web Help based on an > older DocBook XSL version and had a different mechanism for search. Trying to > bring it up to date would've been nontrivial, so I ported the webhelpindexer > into their transform environment instead. I'm getting Java exceptions because > the output isn't fully XHTML compliant. I'm trying to eliminate the Java > exceptions during indexing by adding the XHTML namespace to the stylesheets > and generating XHTML compliant content. When I do this to table.xsl, the > adjustColumnWidth extension function fails and passes through the values > rather than converting them to percentages. > > As it stands, I can leave table.xsl alone and produce plain HTML. Everything > indexes okay. I just get those ugly Java exceptions. I'd rather have a clean > transform. > > Bill Burns > Verbum Communications, Inc. > +1.208.336.6081 > [email protected] > http://www.verbumcomm.com > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: > [email protected] > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJONzbqAAoJEMHeSXG7afUhhv8IAJidbX1soOddpluF2vFH5dRr tNAomY72+eSQ3EsZyPUU/mfSZgcLTUs5CzO2AKg08kAOdsLzuxePYrvfGxPv28Ta Cp5bowjQIn51gLoU6hjLwTOQs/qLVRCOhhE2f2eJBl4y5Q8fP6qBt1bu7zl+zV5y JyFo3GkWOUt0DvXW70i+9vSJ29d34bEtCPv/69OBU0X0jLPZMGznGK/XRm1FDBOO 443ocISRcEeqkJb36m3GLp9yqwy7SvOfpNNj0g022/NQjo6uNPER9JJUYqunsREX sOryn07noCTgSzHMLvAI0OHwNsfnYY1spRcQ+n6QkA63dWc4eo/Y/pKYA835Cpo= =FSvw -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
