Re: The beauty of LATEX
Matias Capeletto <[email protected]>
| Newsgroups | gmane.comp.lib.boost.documentation |
|---|---|
| Message-ID | <CAJiTyxxJ1yN7RfEN1EkMGfPCt_s+-9WNJsjYDRc7jXVMoy3G5g@mail.gmail.com> |
On Sun, Oct 30, 2011 at 2:10 AM, Joel de Guzman <[email protected]> wrote: > 3. Backends: > > a. The template engine is work in progress. The final design > should be powerful enough for tree transformations like the > ones Daniel concocted. > b. The template engine transforms the IR into the final form > (e.g. LaTeX, Docbook, HTML etc.). Can you explain a little bit more how the template engine works to finally transform the IR? Using your example... > We should be working on a full schema and I propose a minimal DocBook > style scheme using simple Qbk/Gaea syntax. Example: > > [book title > [chapter ch1 > [section sect1 > [para ... ] > [para ... ] > [para ... ] > ] > ] > ] I thought that the [para ...] template will get evaluated before the [section ...] one. This will generate something like "<para>...</para>" in the case of the Docbook back-end and that is what the [section ...] template will get as an input. Is that right? >From your comments about footnotes processing for HTML it seems that the [footnote ...] template generates the reference inplace and also returns the actual text for the footnote wrapped in a certain way so it survive the [para ...] evaluation and is then available in the [section ...] template or even in the [chapter ...] one for them to arrange where they will finally end up. Could you elaborate on how the evaluation steps will actually take place? > (aside I'm not sure if we should do it the old way using section/ > endsect, or a real block structure like this. There are tradeoffs, > but I do not want to digress. I'm sure you know what the tradeoffs > are). If you want to follow the design you sketched, I think this is a good change and we should move away from [section] and [endsect]. Best regards Matias