On 30 May 2015 at 17:23, Tobias Blomberg <[email protected]> wrote: > > On 23 maj 2015 12:50 fm "Dan Allen" <[email protected]> wrote: >> >> Kurt, >> >> The blank entry is a reference to the preface (as defined by DocBook; >> AsciiDoc calls it the preamble). It's absence is long-standing issue in the >> AsciiDoc syntax. Because of the way the processor parses this section of the >> document, the preface title never makes it to the right spot. >> >> I addressed this problem in Asciidoctor 1.5.2 by introducing the document >> attribute preface-title. The value of this attribute is used to fill in that >> empty element. > > Wouldn't it be more logical to call it preamble-title to be consistent with > the AsciiDoc naming? > > Or maybe it would be possible to introduce a construct like this? > > [preamble] > == The preamble title == > Preamble contents...
The advantage of Dan's solution is that it can be applied to old documents *with no changes to the document* simply by defining the attribute on the command line, or in a conf file, or in a user conf file. That last option means you can build old projects without even changing the build system or the document. Cheers Lex > > / Tobias > >> >> See https://github.com/asciidoctor/asciidoctor/issues/1090 >> >> We could make the same fix in AsciiDoc Python. >> >> See the following lines: >> >> * https://github.com/asciidoc/asciidoc/blob/master/docbook45.conf#L505 >> * https://github.com/asciidoc/asciidoc/blob/master/docbook45.conf#L703 >> >> -Dan >> >> On Fri, May 22, 2015 at 3:41 PM, Kurt Callaway <[email protected]> wrote: >>> > >>> Hi! >>> >>> I've run into an interesting problem with the Table of Contents in my >>> Docbook/PDF output. It's not clear to me if the way I'm using Asciidoc is >>> at fault, or maybe it is something to do with my docbook toolchain. The PDF >>> outputs always have an anomaly at the start of the auto-generated Table of >>> Contents: the first line is a row of leader dots and a roman numeral page >>> number, but there's no title listed. This odd line always appears first -- >>> either immediately before the first chapter's title; or if I have a preface >>> section defined, before the preface's line in the ToC. I've attached a >>> screenshot of a PDF doc showing this behavior. >>> >>> Might this be caused by Asciidoc processing trying to include a ToC entry >>> for the preamble (which may or may not exist)? >>> >>> Alternately: I have noticed that when I define a Preface section, my XML >>> file has two sets of <preface> elements. Could the first one be causing the >>> phantom ToC line? Here is an excerpt from the XML, after I'd added a line >>> of preamble text after the header and before the real preface (where I have >>> my copyright data): >>> >>> ... >>> </bookinfo> >>> <preface> >>> <title></title> >>> <simpara>Preamble line?</simpara> >>> </preface> >>> <preface id="_preface"> >>> <title>Preface</title> >>> <formalpara><title>Copyright Notification</title><para>Copyright © >>> 1992-2014 ... </para></formalpara> >>> ... >>> </preface> >>> >>> Note in the above that the earliest title element remains null. Any >>> attempt to force a title for that "first" preface block doesn't make any >>> difference. For example adding a floating header gives this XML: >>> >>> ... >>> </bookinfo> >>> <preface> >>> <title></title> >>> <bridgehead id="_first_section" renderas="sect4">first >>> section</bridgehead> >>> <simpara>Preamble line?</simpara> >>> </preface> >>> <preface id="_preface"> >>> <title>Preface</title> >>> <formalpara><title>Copyright Notification</title><para>Copyright © >>> 1992-2014 ... </para></formalpara> >>> ... >>> </preface> >>> >>> Even completely removing the [preface] section from the asciidoc text >>> doesn't help. One preface element disappears, but the spurious null title >>> element remains (and the dots-only row in the ToC is still there too): >>> >>> ... >>> </bookinfo> >>> <preface> >>> <title></title> >>> <formalpara><title>Copyright Notification</title><para>Copyright © >>> 1992-2014 ... </para></formalpara> >>> ... >>> </preface> >>> >>> The PDF is generated using this incantation: >>> a2x -f pdf -a numbered -d book --icons --fop --xsltproc-opts >>> "--stringparam toc.section.depth 4" ./master.txt >>> >>> I looked through the forum here, but haven't seen any previous issues >>> resembling this. Any insights or suggestions would be much appreciated. >>> >>> Thanks, >>> Kurt Callaway >>> Houston, Texas >>> >>> >>> -- >>> 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. >> >> >> >> >> -- >> Dan Allen | http://google.com/profiles/dan.j.allen >> >> -- >> 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. -- 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.
