docbook-apps

Hello,



I'm more of a danger than a developer, but that doesn't stop me from experimenting. I have been working on retrofitting the webhelpindexer to work with an older set of stylesheets (the HTML XSLT from v1.36). I've been eliminating little XHTML errors here and there, but this last one has me stumped.



I moved table.xsl to my customization layer folder and added the XHTML namespace declaration to eliminate the delimiter problems I was encountering. However, an odd thing happened with the calculations for my col widths.



The input is



<colspec colname="col1" colwidth="1*"/>

<colspec colname="col2" colwidth="2*"/>

<colspec colname="col3" colwidth="2*"/>



What is supposed to happen is that the code calculates percentages based on the proportional value, so cols 2 and 3 are both twice the width of col 1. (I have no idea if this code comes from legacy DocBook or if some other developer from my employer wrote it. Smarter people than I wrote it.) When I'm producing plain old HTML, the result is







However, when I add the XHTML namespace, I get this result:







Any clues as to why the calculation would fail with only the addition of the namespace declaration?



Thanks in advance.



Bill Burns

Verbum Communications, Inc.

+1.208.336.6081

bburns@verbumcomm.com

http://www.verbumcomm.com

| -----Original Message-----
| From: Bill Burns
|
| I have been working on retrofitting
| the webhelpindexer to work with an older set of stylesheets
| (the HTML XSLT from v1.36). I've been eliminating little
| XHTML errors here and there, but this last one has me stumped.
|
| I moved table.xsl to my customization layer folder and
| added the XHTML namespace declaration to eliminate the
| delimiter problems I was encountering. However, an odd thing
| happened with the calculations for my col widths.

[...]

| When I'm producing plain old HTML, the result is
|
| | xmlns="" width="40%">
|
| However, when I add the XHTML namespace, I get this result:
|
|


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?

Mauritz

> 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
bburns@verbumcomm.com
http://www.verbumcomm.com

-----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
> bburns@verbumcomm.com
> http://www.verbumcomm.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>

-----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-----

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
bburns@verbumcomm.com
http://www.verbumcomm.com


-----Original Message-----
From: David Cramer [mailto:david@thingbag.net]
Sent: Monday, August 01, 2011 5:30 PM
To: docbook-apps@lists.oasis-open.org
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
> bburns@verbumcomm.com
> http://www.verbumcomm.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail:
> docbook-apps-help@lists.oasis-open.org
>

-----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: docbook-apps-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org