Achim Blumensath writes: > Something I think is difficult to archive with your templates are per > chapter TOCs. If each chapter has its own table of contents there has to > be some method to tell `processcontents' which part it should print. fully correct; the way processcontents is defined this isn't working properly. when i wrote the spec for the new contentsobject data structure i did have `per chapter' tocs etc very much in mind --- one of the reasons for providing sequence numbers (for fast finding the relevant starting point) and providing level information (to easily determine when to stop) so yes, the data structure is set up to more or less provide what is necessary, but the interface for formatting doesn't actually makes use of it. > Either one could add an argument to `processcontents' containing, say, > the serial number of the chapter in question, or `processcontents' has > to get this information from some global variable. The disadvantage of > the first solution is that one has to modify the definitions for some > minor special case, whereas the second case destroys the clean > separation between various parts of the system. i fully agree that using global variables to tell the processcontents templates what to do would make a messy interface and is not the way to do it. i had the first solution in mind originally, no idea why it got lost later on. why do you think it would do so much harm to have such an argument?, e.g. \DeclareTemplate{processcontents}{std}{1} { ... } { \IfNoValueTF{#1} { <make main contents> } { <make partial contents> } } Alternatively one could think of having a special template type just for the partial contents production, eg \DeclareTemplate{processpartcontents}{std}{1} ... this would duplicate a bit of code (eg stuff like handling the start and the ned of a contents list) but makes processing of the main cases (ie full toc) slightly faster. on the other hand, does it matter? how many tocs do you really typeset per document, does some extra \IfNoValueTF ... really hurt? i guess, the next step is to code some templates for partial tocs (perhaps as processpartcontents types as a first solution) and later decide if merging into a single template type looks like a good idea frank