OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: How to handle lost functionality regarding the toc element and lotelement in DocBook 5


While the generation and location of Tables of Content and Lists of
Titles is frequently controlled by the transform, it is sometimes
desirable to allow the author to control whether they are generated. 

At times, a chapter level Table of Contents is very useful, particularly
if the chapter has many sections or complex nesting of sections.  In
other situations, particularly where space is critical (think the manual
shipping with a high-volume product like a camera or printer with a
specific page count restriction) the chapter level ToC may be sacrificed
to meet an arbitrary page count goal (fitting in a half a signature at
the printer).  in the past, we were able to put an empty <toc/> element
as a child of chapter or appendix to trigger the ToC generation.  It
would be desirable to preserve this capability in the new version of
DocBook.

We have also allowed the author to determine which lists of titles are
appropriate for a document.  Again, when trying to make a tight printing
budget this can be quite important -- if you only have a single table in
a book, devoting an entire page to the List of Titles for tables
(actually two pages, since they all start on the odd page) is not very
efficient.  We have used the <lot> element with a role attribute equal
to the formal element (<lot role="table"/>, <lot role="figure"/>, etc.)
to allow the author control over which lists of formal elements are
included.  This also allows us to include a list of procedures at the
front of a chapter with many procedures.  While the function of the role
attribute might better be handled by an enumerated class attribute, the
basic functionality seems desirable for handling special cases without
having to modify XSLT parameters in the build environment.  It also
allows dealing with chapter-by-chapter requirements that are not easily
handled by a rule for an entire book.

Since we publish HTML version of all books as well as the PDFs and want
them to be as consistent as possible, processing instruction seem less
desirable, since it would be necessary to repeat them for the HTML and
PDF if the convention of directing the processing instruction at the
specific output format is to be maintained.

The writeup for DocBook 5.0 says <tocdiv>  replaces the functionality of
<lot>, but it was not clear how this would work.

If eliminating <lot> is desirable, perhaps we could use an empty ToC
with a class attribute or something similar.

Larry Rowland


-- 
=======================================================================
[ Larry Rowland             | If you want to build a ship, don't drum ]
[ ATCL                      | up the men to gather the wood, divide   ]
[ Hewlett-Packard           | the work, and give orders. Instead,     ]
[ 3404 East Harmony Road    | teach them to yearn for the vast and    ]
[ Fort Collins, CO  80528   | endless sea. - Antoine de Saint Exupery ]
[ Phone: 970/898-2280       +-----------------------------------------]
[ FAX:   970/898-2188   E-Mail:larry.rowland@.hp.com                  ]
=======================================================================



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]