Hello,
Following the docbook DTD it is possible to have
construct like the following one
<qandaset>
<qandaentry>
<question>...</question>
<answer>
<para>...</para>
<qandaentry>
<question>...</question>
<answer>...</answer>
</qandaentry>
</answer>
</qandaentry>
</qandaset>
Wouldn't it be nice, if the qandaset ToC could handle
this? ATM it only handles the top-level qandaentries,
but misses all the sub-qandaentries. I've attached a
patch for this situation to apply to qandaset.xsl. It
should work with the DocBook V5.0b6 too. The patch is
really simple and the output then is:
1. foo
1.1 foo sub
1.2 foo next
2. bar
...
Regards, Daniel
Logged In: YES
user_id=1102637
Sorry. Seems I forgot the patch.
Logged In: YES
user_id=1102637
Now I attached a patch. Please have a look at it.
patch to fix this issue
Logged In: YES
user_id=1102637
Maybe a parameter should be added to control this behaviour.
Logged In: YES
user_id=118135
A fix for this issue has been added to the current codebase.
Please test the fix with the latest snapshot from:
http://docbook.sourceforge.net/snapshots/
Logged In: YES
user_id=118135
Applied patch and added new qanda.nested.in.toc param for
controlling the behavior. It's off by default. Setting a
non-zero value for qanda.nested.in.toc turns it on.
Logged In: YES
user_id=1102637
Thanks. I thought, that I hit qandaset/qandaentry with this
code too (Docbook 5 allows qandaset inside answer, but not
qandaentry), but it seems I fail. The xsl-stylesheets in
this case respect the generate.toc parameter, but my code
fails to create a TOC for the sub-sets. I tried this code,
which also fails:
html/qandaset.xsl:
[..]
<xsl:template match="answer" mode="qandatoc.mode">
<xsl:if test="child::qandaentry">
<dd>
<xsl:call-template name="process.qanda.toc"/>
</dd>
</xsl:if>
<xsl:if test="child::qandaset">
<xsl:apply-templates select="child::qandaset"
mode="qandatoc.mode"/>
</xsl:if>
</xsl:template>
<xsl:template match="qandaset" mode="qandatoc.mode">
<dd>
<xsl:call-template name="process.qanda.toc"/>
</dd>
</xsl:template>
[..]
If the output for Docbook 4 and Docbook 5 differs and we/I
do not find a solution, I suggest to remove my patch, so the
behaviour is consistent.
I'm really sorry, but I was sure, this works for Docbook 5
too. Seems I made a mistake.
Regards, Daniel
Logged In: YES
user_id=118135
Daniel,
Please upload a test case (your DocBook XML source).
The current code does seem to me to correctly generate TOCs
for nested DocBook5-valid answer/qandaset instances. I
guess it just doesn't generate them where I guess you're
expecting to find them.
Logged In: YES
user_id=1102637
I would expect the following:
In an article-toc containg qandasets, all question should
appear (currently this only happens for answer/qandaentry,
not answer/qandaset). Inside the qandaset, it is possible to
put all questions into the top-toc (currently
answer/qandanetry) or in every qandaset (currently
answer/qandaset with generate.toc="qandaset toc"). This
isn't IMO a big difference, although I would normally prefer
all questions inside a top-toc and optional a toc per
(sub-)qandaset. But a conistent and complete TOC in an
article-toc would be important.
You can have a look at the difference by processing the
attached testcase in difference to the qandaset.006.xml
testcase.
Regards, Daniel
test case to show the difference between DocBook 4 and 5
result for testcase 6, Docbook 4
result for testcase 7 (I know, case 1 in tests/5.0/), Docbook 5
Logged In: YES
user_id=118135
Daniel,
I made a change that I think will give you what you want.
Please test with the latest snapshot and let me know.
Logged In: YES
user_id=118135
A fix for this issue has been added to the current codebase.
Please test the fix with the latest snapshot from:
http://docbook.sourceforge.net/snapshots/
Logged In: YES
user_id=1102637
Thanks. First, I'm sorry. I found, why my test all failed: I
had the code I suggested still in the customization layer
and so, all my changes to the real stylesheets were ignored
(stupid, I know).
Then: Your changes work except one thing: They only catch
the first instance occurance of a qandaset element inside
another qandaset element (I've attached a testcase to show
you the result - the questions 221 and 222 are not shon in
the ToC) - independent if DocBook 4 or 5 (both only show the
first 2 levels).
Then one thing, I would like to control (at least via your
qanda.nested.in.toc parameter) too: the occurance of theses
sub-sets in the article-toc. In my customization layer I use:
<xsl:template match="section" mode="toc">
<xsl:param name="toc-context" select="."/>
<xsl:call-template name="subtoc">
<xsl:with-param name="toc-context" select="$toc-context"/>
<xsl:with-param name="nodes"
select="section|bridgehead[$bridgehead.in.toc !=
0]|qandaset/qandaentry/question"/>
</xsl:call-template>
</xsl:template>
<xsl:template match="question" mode="toc">
<xsl:param name="toc-context" select="."/>
<xsl:call-template name="subtoc">
<xsl:with-param name="toc-context" select="$toc-context"/>
<xsl:with-param name="nodes"
select="following-sibling::answer/qandaentry/question|following-sibling::answer/qandaset/qandaentry/question"/>
</xsl:call-template>
</xsl:template>
<xsl:template match="question" mode="titleabbrev.markup">
<xsl:value-of select="."/>
</xsl:template>
For me this works with both DocBook 4 and 5.
extended testcase for nested qana* elements
Logged In: YES
user_id=1102637
The issue is related to the check in process.qanda.toc. This
check seems to result in a second issue: if the param is set
to 0, no ToC for qandaset is output, which is not expected.
I've attached a patch to fix this issue (restores the
default behaviour and correct behaviour with enabled
nested-qanda-toc).
HTH
possible patch to finally fix the qandaset-toc code
Logged In: YES
user_id=1102637
Moved the article-ToC customization to
https://sourceforge.net/tracker/index.php?func=detail&aid=1434544&group_id=21935&atid=373750,
where this feature was requested. So if my last patch
finally fixes my original request (which I belive), this
report can be closed.
Logged In: YES
user_id=118135
A fix for this issue has been added to the current codebase.
Please test the fix with the latest snapshot from:
http://docbook.sourceforge.net/snapshots/
Logged In: YES
user_id=118135
Applied patch. Re-open if you notice further problems.