nickoe / asciidoc Goto Github PK

Hello.

First, thanks for the great job you did with this tool.

What steps will reproduce the problem?
1. Currently the footer text will display the "last updated" field as the last 
modification date of the source file. But in certain cases (for example massive 
files generation from a git repository), we would want to have the revision 
date instead, or even nothing.


What is the expected output? What do you see instead?

What I did in the patch is I used a new attribute named "footer-style" that 
could take 3 values:
 - default (or not defined, same as currently)
 - none (not displaying the footer-text section
 - revdate (displays the revision date instead of the source file modification date
Any other value will display only the version number from the footer-text 
section(if defined).



What version of the product are you using? On what operating system?
All versions on all OS.

Please provide any additional information below.
You'll find attached the patch generated with mercurial. It's quite simple.
Be careful, I only did the trick for the english version.

The enhancement was officially asked for debian in 
http://bugs.debian.org/656736 but I also had the need, so I did the change.

If you have any comments, please tell me.

Best regards,
Joseph

A very common need for computer-related documentation is to reference a menu or 
menu selection in a UI. These references are often styled in the output to 
appear the way they do in the UI. Without proper semantics in an AsciiDoc 
document, it's not possible to identify this information in the output.

I propose adding an inline menu macro that recognizes the following syntax:

menu:File[]
menu:File[Close]
menu:File[New,Message]

The target slot is the name of the menu. The last attribute is the name of the 
menu item. Any attribute preceding the last attribute is assumed to be a 
submenu.

In the docbook backend, the menu is mapped to <guimenu>, the submenu to 
<guisubmenu> and the menu item to <guimenuitem>. A selection is wrapped in 
<menuchoice>.

<guimenu>File</guimenu>
<menuchoice>
  <guimenu>File</guimenu>
  <guimenuitem>Close</guimenuitem>
</menuchoice>
<menuchoice>
  <guimenu>File</guimenu>
  <guisubmenu>New</guisubmenu>
  <guimenuitem>Message</guimenuitem>
</menuchoice>

In the html backend, these element names become class names on <span> elements.

I've included an implementation and a page that shows examples in a gist:

https://gist.github.com/mojavelinux/4736691

Translated strings 'Version' and 'Last updated'.

Hi,

the Czech language uses the same quote style as German, i.e. opening with the 
low quotation mark, closing with the high quotation mark.

Patch attached.

Example AsciiDoc source (with line number, contain Chinese characters):
1: 这是一个测试
2: ------------

If you want to generate document with the code above, currently AsciiDoc 
(version 8.6.3) will produce error like this:
asciidoc: ERROR: alist.txt: line 1: [blockdef-listing] missing closing delimiter

AsciiDoc mistakenly treat line 2 (the '-') as delimited block when in lex 
stage. Because the length of line 1 is 6, however its column width is 12. 
AsciiDoc just compare the two lines' length, actually should compare their 
column width.

So I submit this patch, reference to reStructuredText's code, hope it helps.

What steps will reproduce the problem?
1. Add ((H~2~O)) to a book text.

What is the expected output? What do you see instead?
The water molecule, instead we get "H2O" at index entries. 


What version of the product are you using? On what operating system?
asciidoc-8.6.8 - ubuntu.

Please provide any additional information below.

On page "Publishing eBooks with AsciiDoc"
http://www.methods.co.nz/asciidoc/publishing-ebooks-with-asciidoc.html
last link (to "AsciiDoc web site") is broken:
it renders as href="http:///www.methods.co.nz/asciidoc/" (note ///)
and (at least in Opera) work as http://0.0.0.0/www.methods.co.nz/asciidoc/

The symbol + can be problematic when it occurs in inline text. While there are 
other ways to escape it, it seems to be a good candidate as an intrinsic 
attribute for the same reason several of the others (e.g., two-colons, 
two-semicolons, etc) where selected.

This issue is a feature request to add the following attribute definition to 
asciidoc.conf

[attributes]
plus=+

This can be used inline as {plus}.

...which would render:

This can be used inline as +.

What steps will reproduce the problem?
1. configure --prefix=/some/custom/dir
2. make install

What is the expected output? What do you see instead?
Step 2 should install all files to prefix /some/custom/dir.
Instead, some vim files are installed into /etc/vim.

What version of the product are you using? On what operating system?
Latest hg tip

Please provide any additional information below.
This is unfortunate when e.g. installing to a user-specific stow directory.

Patch is attached.

What steps will reproduce the problem?
1. Do not have xmllint in the PATH
2. Run a2x on doc source that would create an intermediate xml file

What is the expected output? What do you see instead?
a2x fails, complaining about not being able to find xmllint.

What version of the product are you using? On what operating system?
This is still in trunk.

Please provide any additional information below.
Should be something like:
    XMLLINT=(subprocess.call(["which", "xmllint"], stdout=subprocess.PIPE) == 0 and "xmllint" or "")

Using certain verbatim latex environment lead to problems as these environments 
expect a newline. 

The dovetail function strips all newlines for the verbatim blocks.
The proposed patch adds a asciidoc tag to indicate the newline must not be 
removed.

Element for latex.conf

[listingblock]
\\minisec\{{caption=Listing: }{title}\}
\label\{{id}\}\hypertarget\{{id}\}\{\}
\begin\{lstlisting\}[breaklines]
!..newline..!
|\end\{lstlisting\}



Patched function

def dovetail(lines1, lines2):
    """
    Append list or tuple of strings 'lines2' to list 'lines1'.  Join the last
    non-blank item in 'lines1' with the first non-blank item in 'lines2' into a
    single string.
    """
    assert is_array(lines1)
    assert is_array(lines2)
    lines1 = strip_list(lines1)
    lines2 = strip_list(lines2)
    if not lines1 or not lines2:
        return list(lines1) + list(lines2)
    if (lines1[-1]=="!..newline..!"):
            return list(lines1[:-1]) + list(lines2)
    if (lines2[0]=="!..newline..!"):
            return list(lines1) + list(lines2[1:])
    result = list(lines1[:-1])
    result.append(lines1[-1] + lines2[0])
    result += list(lines2[1:])
    return result

I'd like to request for the HTML blockquote and cite tags in the quote block 
template for the html5 backend.

Currently, the quote block is rendered entirely using HTML div elements. The 
current approach lacks the proper semantics for a quote block and it renders as 
a regular paragraph without the AsciiDoc stylesheet.

By switching to blockquote and cite tags, it makes rendering in places that 
don't have a AsciiDoc-specific stylesheet look reasonable, in addition to it 
being more semantically correct.

I propose the following template in the quote block for the html5 backend:

[quoteblock]
<div class="quoteblock{role? {role}}{unbreakable-option? unbreakable}"{id? 
id="{id}"}>
<div class="title">{title}</div>
<blockquote>
|
</blockquote>
<div class="attribution">
<cite>{citetitle}</cite>{attribution?<br>}
&#8212; {attribution}
</div></div>

This change requires two minor additions to the AsciiDoc stylesheet:

cite {
  color: navy;
}

blockquote {
  padding: 0;
  margin: 0;
}

If the asciidoc.footnotes() function is called twice (such as if the reinstall 
timer is triggered), then all footnoterefs are renumbered to 'undefined' and 
broken. The attached patch solves this by only renumbering footnoterefs when a 
valid number is found for them:

diff -r 7863b0a0ab0d -r 1dad4b041c4a javascripts/asciidoc.js
--- a/javascripts/asciidoc.js   Wed Nov 27 21:59:21 2013 +1300
+++ b/javascripts/asciidoc.js   Tue Apr 15 09:09:29 2014 -0600
@@ -156,9 +156,11 @@
         var href = spans[i].getElementsByTagName("a")[0].getAttribute("href
         href = href.match(/#.*/)[0];  // Because IE return full URL.
         n = refs[href];
-        spans[i].innerHTML =
-          "[<a href='#_footnote_" + n +
-          "' title='View footnote' class='footnote'>" + n + "</a>]";
+        if (n) {
+          spans[i].innerHTML =
+            "[<a href='#_footnote_" + n +
+            "' title='View footnote' class='footnote'>" + n + "</a>]";
+        }
       }
     }
   }

https://github.com/kghost/asciidoc/commit/4311d7f699b9ddaccbc421150ca35823e5d681
69

a2x.py is not compatible with Python 2.4 (as is claimed in the installation 
instructions) because it uses str.endswith() with a tuple instead of a simple 
string as an argument. See 
http://code.google.com/p/asciidoc/source/browse/a2x.py#443. The signature 
accepting a tuple was introduced in Python 2.5, see 
http://docs.python.org/library/stdtypes.html#str.endswith.

> What steps will reproduce the problem?
1. create a text file and a new folder in the current directory
2. cd to the folder
2. call "a2x -D . -L -a toc -v -d book -f pdf ../foo.txt"

> What is the expected output? What do you see instead?

The file created is ../foo.pdf and not foo.pdf

> What version of the product are you using? On what operating system?

asciidoc-8.4.5-4.2.noarch (opensuse 11.3)

What steps will reproduce the problem?
1.  Use -e to specify and specify all config files on command line with -f 
2.  Run doc build -b docbook -d book
3.  Produced docbook file is wrong

See [1] for more details.  

[1] 
http://groups.google.com/group/asciidoc/browse_thread/thread/cd0f47495fd04181#

What is the expected output? What do you see instead?

Correct docbook files. Some macros/attributes are not expanded correctly.

## Command line to build book.txt 
./asciidoc-8.6.4/asciidoc.py -f asciidoc-8.6.4/asciidoc.conf -f 
asciidoc-8.6.4/docbook45.conf -f asciidoc-8.6.4/lang-en.conf -f 
asciidoc-8.6.4/filters/code/code-filter.conf -f asciidoc-8.6.4/filters/ 
source/source-highlight-filter.conf -f asciidoc-8.6.4/filters/graphviz/ 
graphviz-filter.conf -d book -b docbook -o b.xml -ev ./book.txt 
asciidoc: reading: asciidoc-8.6.4/asciidoc.conf 
asciidoc: reading: asciidoc-8.6.4/docbook45.conf 
asciidoc: reading: asciidoc-8.6.4/lang-en.conf 
asciidoc: reading: asciidoc-8.6.4/filters/code/code-filter.conf 
asciidoc: reading: asciidoc-8.6.4/filters/source/source-highlight- 
filter.conf 
asciidoc: reading: asciidoc-8.6.4/filters/graphviz/graphviz- 
filter.conf 
asciidoc: reading: /home/haad/Desktop/misc/asciidoc/book.txt 
asciidoc: WARNING: book.txt: line 5: missing section: [sect1] 
asciidoc: WARNING: book.txt: line 5: missing section: [sect1] 
asciidoc: WARNING: book.txt: line 5: missing section: [sect1] 
asciidoc: WARNING: book.txt: line 5: missing section: [sect1] 
asciidoc: writing: /home/haad/Desktop/misc/asciidoc/b.xml 
asciidoc: WARNING: book.txt: line 5: missing section: [header] 
asciidoc: WARNING: book.txt: line 28: missing section: [sect2] 
asciidoc: WARNING: book.txt: line 33: missing section: [sect1] 
asciidoc: WARNING: book.txt: line 71: missing section: [sect2] 
asciidoc: WARNING: book.txt: line 75: missing section: [sect3] 
asciidoc: WARNING: book.txt: line 79: missing section: [sect4] 
asciidoc: WARNING: book.txt: line 88: missing section: [sect1] 
asciidoc: WARNING: book.txt: line 96: missing section: [sect1] 
asciidoc: WARNING: book.txt: line 108: missing section: [sect2] 
asciidoc: WARNING: book.txt: line 156: missing section: [footer] 

What version of the product are you using? On what operating system?

Thi worked on asciidoc 8.5.3 and was broken on > 8.6.3 

Please provide any additional information below.

Attached patch fixes problem for me. It adds support for two stage config file 
loading when we use -e parameter.

An open block can masquerade as any type of delimited block except a pass 
(passthrough) block. With a small addition to asciidoc.conf, an open block 
could work as a pass block when assigned the pass style.

For example, these two blocks should be equivalent:

++++
<h1>AsciiDoc</h1>
++++

and

[pass]
--
<h1>AsciiDoc</h1>
--

Here's the line that needs to be added to asciidoc.conf to support this feature:

[blockdef-open]
...
pass-style=template="passblock",subs=("attributes","macros")

We could also add another one that disables all subs

[blockdef-open]
...
pass_-style=template="passblock",subs=()

I'm not sure how to make the subs something that can be controlled from the 
markup.

I suggest making the background white because if a large image (for example) in 
the main document creates an horizontal scrollbar, scrolling the main document 
on the right will show up the left-most test and pictures mixed up with the toc 
text.

At least on Firefox, but I suppose it's a standard to assume the background is 
transparent by default.

Thanks,
Lionel

On 10 October 2012 04:34, Jens ... wrote:

I observed the following behavior:

Without :data-uri: directive: Paths in subdocuments to images are relative to 
the location of the main document.
With :data-uri: Paths in subdocuments to images are relative to the location of 
the subdocument.

I usually use the 2. because my subdocuments are independent projects with 
separate resources. Unfortunately not all backends implement the 2. correctly 
yet. For example the html4 and odt backends do not therefore my projects do not 
compile with these backends.




Am Mittwoch, 10. Oktober 2012 00:49:06 UTC+2 schrieb Lex Trotman:
--------------------------------------------

They should all follow type two, but there is a bug(s).


    @Stuart, documentation says images are relative to the referring document.  Data-uri correctly uses {indir}/{imagesdir}/{target} but non data-uri uses {imagesdir}/{target} which makes them relative to the *working* directory (if {imagesdir} is not absolute), not the document directory. It is therefore wrong if for example the document is an included document from another directory, or asciidoc wasn't run in the document directory.

    Documentation doesn't mention absolute being accepted, but I'll bet there are lots of documents that depend on that :( so it isn't just as simple as sticking an {indir={outdir}} on the front for non-datauri I don't think.

Further details see topic:

https://groups.google.com/forum/?fromgroups=#!topic/asciidoc/yazroFPc4ow

What steps will reproduce the problem?

Run this on OSX 10.6.7 (with either python 2.6.1 or python 2.7.1)
1. autoconf
2. ./configure
3. make

What is the expected output? What do you see instead?
Leads to this error:
Fixing CONF_DIR in asciidoc.py
Fixing CONF_DIR in a2x.py
python a2x.py -f manpage doc/a2x.1.txt
a2x: ERROR: xmllint --nonet --noout --valid 
/Volumes/raptor/dev/opensource/asciidoc/doc/a2x.1.xml returned non-zero exit 
status 4
make: *** [doc/a2x.1] Error 1

What version of the product are you using? On what operating system?
asciidoc 8.6.4, on OSX 10.6.7, tried with stock python 2.6.1 and tried 
upgrading python to 2.7.1

What steps will reproduce the problem?
1. Use an e-mail address containing a plus sign in your document. Such e-mail 
addresses are e.g. used by googlegroups: [email protected].

What is the expected output?

The [email protected] e-mail address rendered as clickable link 
(in xhtml output).

What do you see instead?

mylist+ is not part of the link.

What version of the product are you using? On what operating system?

asciidoc from hg, revision 7863b0a0ab0d. Debian 7.2

Thanks!
- reet

Output of HTML and DocBook could be properly indented. Either an option to do 
this post processing or indent the output correctly is desired

What steps will reproduce the problem?
1. Create asciidoc document containing manpage

2. Assign title containing hyphen, e.g. MY-TITLE(1) 

3. attempt to build using
  > asciidoc -o <manpage_name>.xml -b docbook -d manpage   
  <manpage_name>.txt

What is the expected output? What do you see instead?
Expected output is a valid XML file

Seeing error
asciidoc: FAILED: manpage document title is mandatory


What version of the product are you using? On what operating system?
asciidoc 8.6.6

Please provide any additional information below.

Attempted to correct problem by escaping '-',
  MY\-TITLE(1)

A very common need for computer-related documentation is to reference a key or 
key combination on a keyboard. These references are often styled in the output 
to appear as keys on a keyboard. Without proper semantics in an AsciiDoc 
document, it's not possible to identify this information in the output.

I propose adding an inline key macro that recognizes the following syntax:

key:[Enter]
key:[Ctrl+Shift+T]
key:[Ctrl+N]

I'm also considering using the target slot for a single key reference:

key:Enter[]

We could consider using the attributes for the modifiers and the target for the 
final key, as in:

key:N[Ctrl]

...however, I'm quite certain documentation writers won't find that intuitive.

In the docbook backend, each key character is mapped to <keycap> and multiple 
keys are wrapped in <keycombo>.

<keycap>Enter</keycap>
<keycombo><keycap>Ctrl</keycap><keycap>N</keycap></keycombo>

In the html backend, these element names become class names on <span> elements.

I've included an implementation and a page that shows examples in a gist:

https://gist.github.com/mojavelinux/4736691

As discussed on the mailing list .. adding .adoc, .asc and .asciidoc as 
supported by github.

The <tt> element has been deprecated in HTML 5 [1]. Since the HTML 5 backend is 
intended to output conforming HTML 5, the use of <tt> should be replaced by one 
of the inline literal elements recommended by the W3C. The most obvious choice 
is <code>.

"for computer code, consider the code element"

Here's the snippet from the AsciiDoc html5 backend that makes this switch:

[literal-inlinemacro]
<code>{passtext}</code>

[tags]
monospaced=<code{1? class="{1}"}>|</code>

[monospacedwords]
<code>{words}</code>

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#tt

The $(DESTDIR) approach in Makefile.in does not follow the autoconf standard. 
The current make file does not work properly with
    configure --prefix=XXXX
The attached patch fixes the problem.

Captions are currently auto-generated for example, figure and table blocks. 
Numbering code listing blocks is a very common requirement for technical 
articles. Therefore, I think listing blocks should be added to the built-in set 
of blocks that get auto-numbered.

This requires a change to both the listingblock template and the 
source-highlight-block template (if in use).

The first step is to define a caption prefix in the language file:

[attributes]
listing-caption=Listing

The next step is to set the fallback caption in the listingblock in html 
backends. Here's the template for html5.conf.

[listingblock]
<div class="listingblock{role? {role}}{unbreakable-option? unbreakable}"{id? 
id="{id}"}>
<div class="title">{caption={listing-caption} {counter:listing-number}. 
}{title}</div>
<div class="content monospaced">
<pre>
|
</pre>
</div></div>

Here's the source-highlight-block template for the xhtml and html5 backends in 
source filter configuration file:

[source-highlight-block]
<div class="listingblock{role? {role}}">
<a name="{id}"></a>
<div class="title">{caption={listing-caption} {counter:listing-number}. 
}{title}</div>
<div class="content">
{source-highlighter$highlight:}<pre><code>
|
{source-highlighter$highlight:}</code></pre>
</div></div>

The error: 

./asciidoc.py -v -d article --unsafe --backend=latex -f ./latex.conf Example.txt
asciidoc: reading: /tmp/asciidoc-8.6.8/asciidoc.conf
asciidoc: reading: ./latex.conf
asciidoc: reading: /tmp/asciidoc-8.6.8/asciidoc.conf
asciidoc: reading: Example/txt
asciidoc: reading: /tmp/asciidoc-8.6.8/latex.conf
asciidoc: reading: /tmp/asciidoc-8.6.8/filters/music/music-filter.conf
asciidoc: reading: /tmp/asciidoc-8.6.8/filters/latex/latex-filter.conf
asciidoc: reading: /tmp/asciidoc-8.6.8/filters/graphviz/graphviz-filter.conf
asciidoc: reading: /tmp/asciidoc-8.6.8/filters/code/code-filter.conf
asciidoc: reading: 
/tmp/asciidoc-8.6.8/filters/source/source-highlight-filter.conf
asciidoc: WARNING: Example.txt: line 2: missing section: [source-filter-style]
asciidoc: FAILED: Example.txt: line 2: malformed section entry: 
template::[source-filter-style]

is caused by a conditional defintion of the template source-filter-style. 
For now I just made an empty definition of the filter when compiling for latex 
(is this a NULL filter?).

In AsciiDoc, you can hard wrap paragraphs of text and they will be combined 
into a single paragraph. While this is expected behavior for some people, to 
others it's not.

Add a feature to AsciiDoc to treat newlines in paragraph content as real line 
breaks.

The next paragraph contains two phrases separated by a single newline character:

Roses are red
Violets are blue

When the following attribute is set:

:hardbreaks:

AsciiDoc would output (when using an HTML backend)

Roses are red<br>
Violets are blue

(naturally, other backends would use the appropriate line break character).

I propose for this substitution to occur where ever the line break character 
(+) is processed.