[...] > After looking at asciidoc source tree, things are not really clear to me, > but if at the asciidoc parsing time, the caption information is not > available, could it be a good approach to: > (1) have the HTML backend just produce some specific markup which contains > enough information. > (2) Then the asciidoc engine would allow backend to provide a postprocessing > pass. > (3) HTML backends would use that pass with some transform like xslt to > produce the HTML we want. > > What do you think ?
Hi Stéphane, There are two parts to Asciidoc, - the definition of a lightweight **content** markup language - a Python implementation of a translation engine from the Asciidoc markup to various HTML flavours, or docbook, and experimentally ODF and Latex. These are unfortunately somewhat mixed together in the user guide. That implementation is a single pass translator, that is configured by backends for that implementation, to define the **format** of the output. It does **not** define the presentation of the output. Output presentation is defined by toolchains which operate post Asciidoc. Asciidoc does not provide presentation handling, but backends may allow inclusion of information for the toolchains, but it does not process any of it. For example docinfos for docbook, css for HTML, resource info for ODF. For docbook its clear what these toolchains are, you have already noted them. And the a2x Python script is provided to ease running them. What may not be clear is that this applies to HTML too. The browser is the toolchain and the processing is defined by CSS and Javascript. The Javascript generates the table of contents and footers, they are not generated by the Asciidoc translator since it is single pass and does not have the information to generate them (especially as the toc is usually output *before* any of the contents it refers to). This limitation on available information to the translator also applies to xref links (especially forward ones). The advantage of the single pass implementation is however that it does not have any limits on the size of the document it processes. What this long winded intro is coming to is that therefore you should look at modifying the HTML **toolchain** to perform the link processing, ie the Javascript. The Javascript for the TOC provides an example of such post processing, a similar Javascript could modify the link text to the text labelled by the link if the xref was captionless (ie the text was the link in []). Cheers Lex PS Nothing is as perfect as its model suggests :) eg the asciidoc translator does do some presentation generation in the HTML backends, such as section numbering. PPS There is also a Ruby implementation (asciidoctor) that accumulates the whole document in memory and does static toc and footer generation, this allows it to be used in places like Github README markup where it can't serve Javascript. But this is of course blurring the lines of presentation and content further. > > Thank you for your attention. > > -- > Stéphane Gourichon > > -- > You received this message because you are subscribed to the Google Groups > "asciidoc" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/asciidoc. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/asciidoc. For more options, visit https://groups.google.com/d/optout.
