Boost logo

Boost :

Subject: Re: [boost] Process discussions
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2011-02-02 06:47:17

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of John Maddock
> Sent: Wednesday, February 02, 2011 9:21 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Process discussions
> > It shouldn't require huge changes. For the most part, the anchor names
> > are based on the name of whatever they're for. There are just a few
> > cases that aren't handled.
> >
> >I had a look at the math docs and a lot of the anchors are generated
> >for bridgeheads (headings). So I tried changing quickbook to give these
> >ids and it made a huge difference. The change is on the increasingly
> >inappropriately named branch at
> >
> Thanks Daniel!


PS I note another reason to perhaps use sections more and headings less is
the effect on indexing.

(If I haven't misunderstood - again -) with John's autoindexing (or any
other indexing system for that matter) when viewing html, the index term
only gets the user to the right *section*. If you have pages and pages of
stuff using many headings (rather than splitting into sections), then the
user may have search through many pages past many headings to find what is
sought. This is easy enough using the web browser find, but a hassle, and
risks finding items with the same word, but not the item to which the index
term referred.

(With pdf native indexing, the index term hyperlink gets to the right
*page*, so it's not such an issue. But we should be structuring for both
html and pdf).

Of course, sections also appear on the Table of Contents, which will become
bigger, perhaps bloated even, if you have too many (sub) sections.

Another issue is that I find it too easy to get my section and endsects
mismatched. (And I find that the diagnosis of mismatching brackets isn't
always user friendly). More sections will give me even more chance of
getting in a muddle!

Boost list run by bdawes at, gregod at, cpdaniel at, john at