On 28/11/11 12:16, j. van den hoff wrote:
On Sun, 27 Nov 2011 23:35:56 +0100, Stuart Rackham <[email protected]> wrote:
On 28/11/11 09:31, j. van den hoff wrote:
On Sun, 27 Nov 2011 20:52:53 +0100, Stuart Rackham <[email protected]> wrote:
On 28/11/11 03:40, jvdh wrote:
I hope this is the right place to ask such basic questions...
It is.
why does this input
//----------
CUT--------------------------------------------------------------
= problem
A. Einstein
I. Newton
. M. Born
//----------
CUT--------------------------------------------------------------
generate this formatted (html) output:
//----------
CUT--------------------------------------------------------------
problem
1. Einstein
2. Newton
1. M. Born
//----------
CUT---------------------------------------------------------------
I do not understand two things:
1. why are the first two lines (after the title) apparently converted
in
two implicit (auto-numbered) list entries although they don't start
with a
`.'?
why are the initial letters dropped altogether? I would have
guessed
that the lines are treated as explicitly 'numbered' list items as
explained in the manual.
The second explicitly numbered item should read:
I) Newton
I actually did not really want the list but the strings themselves (i.e. first
name initial letter plus second name). I presumed that "single alphanumeric
character plus dot" would always count as explicit list numbering but I know see
that this is wrong.
i.e. a right parenthesis instead of a dot ('I.' is seen as an upper case alpha
item, same as previous item but out of sequence, hence the warning message).
See http://www.methods.co.nz/asciidoc/userguide.html#_numbered_lists
I don't know why your first two list items are arabic and not upper alpha,
here's what I get when I ran you example:
8<----------
A. Einstein
B. Newton
1. M. Born
8<----------
it's definitely what's happening here and I sure did nothing fancy with the
configuration. if this is not user settable anyway: where and how can this
happen? any guess?
It's a mystery, I ran a pristine copy of 8.6.5 on your test file and got the
expected output (the warning is expected). Please do the same and post the
result as per below:
guest@xubuntu-1004:~$ cat t.txt
= problem
A. Einstein
I. Newton
. M. Born
guest@xubuntu-1004:~$ python asciidoc-8.6.5/asciidoc.py -v t.txt
I have done this and checked the html output more closely. I've previously only
tested `elinks' (a text based browser). now I checked also with `lynx', `w3m'
and `opera'. result: all the text-based browsers show erroneous numeric labels
as I reported in my previous mail. Opera shows what you expect (i.e.
"upperalpha" labels).
so this seems for some reason only to happen in `lynx' and relatives, but why
they do misinterpret "upperalpha" is a mystery to me. for completeness I've
attached the resulting html file but I'm quite sure it's the same as yours will
be.
does this make sense to you?
lynx and relatives are not (mostly due to character display constraints) CSS
conformant. asciidoc styles the upperalpha lists using 'list-style-type:
upper-alpha;' CSS. So the problem is due to lynx limitations.
Cheers, Stuart
...
ps: if you don't mind: should {zwsp} not have zero width when viewing the html
output in a browser?
``Normally it isn't a visible separation, but it may expand in passages that
are fully justified.'' -- http://en.wikipedia.org/wiki/Zero-width_space
yes, I found that and read it but do not understand what "fully justified" means
here. something like
`A{zwsp}. Einstein' does not fill up the line in the display but there is a
visible space after the `A'. but anyway that's not relevant (for me) now that I
know of
the {empty} directive.
thanks again for taking the time to respond,
joerg
--
You received this message because you are subscribed to the Google Groups
"asciidoc" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/asciidoc?hl=en.
