On Mon, Dec 03, 2012 at 06:32:42PM +0100, Thien-Thi Nguyen wrote: > > * sectionning tree. I think that, in addition to the node tree, the > sectionning tree (@part, @chapter, @section, @unnumbered...) should be > present and index the corresponding nodes too. > > Is there a strict 1:1 correspondance between elements of the sectioning > tree and elements of the node tree? Can a section have zero or multiple > nodes? Can a node have zero or multiple sections?
No 1:1 correspondance in both directions. Having nodes without sectioning commands should not be a problem. Sections without node directly associated could be handled in different ways. The simplest would be to link to the node containing the section. It could also be possible to link to the section more directly. > Presently, in META, the last element is usually ‘(contents (@))’. How > about replacing that element w/ the sectioning tree? Another idea is to > place it after the index, so that the file format looks like: > > MAGIC > META > COUNTS > INDEX > S-TREE > NODES > > Maybe that would be more straightforward, since S-TREE can refer to the > node indices (0 for "Top", etc), then. I agree it would be better that way. > And the processor should be able to process an information of a > change in those. Some may not be needed, in fact if the > information is already in the XML (for instance, I think clickstyle > is also in an attribute of @click or something like that). > > Hmm, i suppose there should be another place to specify nodes that > modify settings. The processor must accumulate these. Something like: > > ... > INDEX > S-TREE > (TWEAK...) > NODES > > where TWEAK is ‘(INDEX (NAME VALUE)...)’. In this case, we could > actually move (some of the) SETTINGS out of META and into the list of > TWEAKs, as the first one: ‘(0 (NAME VALUE)...)’. If "Top" has its own > tweaks, those would have to be merged -- no big deal (i think). To be more rapid, the state at the beginning of the node could be specified for each node. That way the processor do not need to accumulate but can directly access the node. I don't really get what is special about "Top" node tweaks. > * index of indices entries. At least the node containing the indices > entries (@cindex...) should be indexed somewhere, to be able to > format a printindex. > > Agreed -- see TLI in COUNTS. E.g., hello.ixin says ‘((cp 6))’. Or am i > misunderstanding something? The location of printindex is important, but this is not what I was referring to. For the formatting of printindex, all the index entries must be easy to access. > I that that it would be even better to have > an XML representation of the index entry text. > > Yes. That info should lie in the node, i'd think. To be able to format a printindex rapidly, the index entries should be easy to access directly, so, in my opinion all should be in the file (duplicated) with the beginnning and end offsets just like nodes. -- Pat
