On 12/08/2011 04:58 PM, Jean-Marc Lasgouttes wrote:
> I would gather stuff in InsetFoot::validate method. This is the place
> for two pass handling of output.
>
I see the overall point, but I was thinking of gathering it during
output for reasons connected with how I'm imagining doing the "chapter
splitting" version. We actually have easy reference to each of the
footnotes already in the TOC, so we can simply use those if we're only
printing footnotes the one time. In this case, I was imagining something
like the following:

Instead of a simple odocstream during output, we have a stack of
odocstringstreams. As new chapters or sections open (actually, this will
be controlled by the TOC level), we put a new stream on the stack, which
will eventually become the separate file for that level, and of course
we write a link to it in the previous file. As we come to the end of
each one, we write the footnotes for that section. So we need to know
which ones "those" are, i.e., which ones are in "that section", and an
easy way to figure that out is to have collected pointers to them as we
went, again in a stack-like structure.

Another way would be to collect relevant information in the footnotes
themselves as we validate so we can figure out which ones we need to
write. This would be similar to what is done in updateBuffer() for
InsetMathHull or InsetLabel. We might, e.g., record the values of the
section and chapter counters, and use some other hack for section*, etc.
We could probably also do this kind of thing in validate(), since I
don't think we actually need the values of the counters (as we do in the
other case).

Either way will work, but doing it as we go seemed more natural when I
was first thinking about it.

Richard


> Richard Heck <rgh...@comcast.net> a écrit :
>
>     On 12/08/2011 03:42 PM, Rob Oakes wrote:
>     > Hi Richard, 
>     >
>     > Just trying to implement the gathering of footnotes via std::list. I 
> placed the structure in the LatexFeatures header, however, I didn't see any 
> way to access LatexFeatures via OutputParams (e.g. op.features ...). Am I 
> missing something obvious?
>     >
>     Probably needs to be put in OutputParams, then. You might model it on
>     how it's done with exportdata.
>
>     rh
>
>

Reply via email to