On Sep 24, 2004, at 1:05 AM, Joel wrote:
Joel wrote:

6) Why are:
    <bridgehead>Heading 1</bridgehead>
    <bridgehead renderas="sect2">Heading 2</bridgehead>
    <bridgehead renderas="sect3">Heading 3</bridgehead>
    <bridgehead renderas="sect4">Heading 4</bridgehead>
    <bridgehead renderas="sect5">Heading 5</bridgehead>
    <bridgehead renderas="sect6">Heading 6</bridgehead>
    not doing the right thing? See http://tinyurl.com/5otwq
    under Headings.

This generates:

<h3>Heading 1</h3>
<h2>Heading 2</h2>
<h3>Heading 3</h3>
<h4>Heading 4</h4>
<h5>Heading 5</h5>
<h3>Heading 6</h3>

[see http://tinyurl.com/6bhhp]

Which is clearly wrong.

The <bridgehead> element, in the absence of a renderas attribute, picks the next <hN> based on the nesting. So because you're inside a section in an article (h2 and h1), it chooses h3 for Heading 1. For Heading 2, the DocBook XSL is clearly just missing the case where it checks for sect6 (it only enumerates sect1-sect5). It's a trivial fix (that will go in later).


.... And one last unanswered question:

I noticed that boostbook generates html with the format:
a.b.c.d.e.html. This convention makes it very difficult
to limit the filename to less than 32 characters (as required by
boost). For example, here's a file from the boostbook docs:
boostbook.dtd.template-nontype-parameter.html. Wouldn't it be
better if we use nested directories instead?

Nested directories are, unfortunately, really, really hard to create from within XSL (some processors do it, some don't). There are a few things we'll need to do:
1) Put in a limiter that avoids generating IDs that are longer than 26 characters (+ the ".html" extension to hit 31). This is about 4 lines of XSL in one place; very easy.
2) Monkey around with the ID scheme so that we don't generate things like a.b.c.d.e until they're actually needed to make it unique. There's no reason for struct.boost.layout_tolerance.html when layout_tolerance.html would be unique. This takes a little more work.


        Doug



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Boost-docs mailing list
[EMAIL PROTECTED]
Unsubscribe and other administrative requests: 
https://lists.sourceforge.net/lists/listinfo/boost-docs

Reply via email to