World: r3wp

@Ashley

1) a <title> option for =table. Yes, I considered this. HTML has 
a caption option for tables and optional align (top|bottom). If align 
isn't there, it's up to the browser to deside. I found it a bit confusing, 
and by putting the title of the table yourself at the place, you 
want, you get the result as expected.

2) a right option for =image. Yes, good idea. I've also considered 
the situation, where text should go around images. But I haven't 
found a good way to specify that yet.

3) Is "/" needed in state off tags? Yes, I think so, because it's 
easier to understand, if you have e.g. several bolds after each other. 
Example:

This is some [b]text[/b], where there are [b]several examples [/b]of[b] 
bold[/b] words.
is easier to understand than:

This is some [b]text[b], where there are [b]several examples [b]of[b] 
bold[b] words.

Also if you make a style, that is bold, then you wan't to use [/b] 
to undo bold. Would be confusing, if you used [b] for that too.

wan't = want !!! grrr, irritating error to make. ;-) Well, I'm partly 
from Faroe Islands, so bear with me.

@Robert

I've looked at how MDP handle bold, italic and so, and it almost 
work as expected. I can't figure out, how to make text both bold 
and italic. Also my math examples from above is not giving me the 
expected result.

*1 + 2 = ?
is shown as a bullet point, as I expect, but the '=' is removed.

*1 * 2 = ?

is NOT shown as a bullet point, and I expected that. It's not bold 
either. The result is:
*1 * 2 ?
again without '='.

I like *bold*, ~italic~, _underline_ and -strike- notation too, but 
I'm afraid, it will give problems for some users. What if you want 
to have a part of a word in bold? How will you write a mathematical 
expression with - and *? You could of course use the escape character 
(\) for that, but then you'll have to do that every time, you use 
- and *. What shall the rules be with bullet points and *bold*? No, 
I think, we need something else in the document format, and then 
let users have the option to use *bold*, ~italic~ and so notation 
in a word processor, which can be based on the new document format 
anyway.

About 2) left and right options for =image. Now that I've defined 
the paragraph level state changes =center, =left and =right, it isn't 
necessary to have left and right options for =image. To e.g. have 
right alignment for only the image, you can write:

=right
=image <file!>
=left

Is that good enough?

Logical extension of the "change of state" rules, works for me. ;)

I'm a bit in two minds about alternative ways of doing things. Maybe 
it IS a good idea to be able to also put left and right on =image? 
Is it general a good thing to be able to do the same thing in more 
than one way in a standard like this, or is it just more confusing 
then?

as user i would think about the image, how can i move it. using the 
paragraph to move the image is more tricky. also: can a text be at 
the left side of an image and then centered in that space?

mixing: At the moment MDP doesn't support bold AND italic.

= char: = is used to start a directive, so the simple character should 
work. Looks like a bug :-))

markup style: Try it, * and - can be used standalone and inside words 
without sideeffect. No bold etc. is turned on ;-)) I'm sure I handle 
99% of all cases as the user expects.

bold and bullets are handled correctly in mixed cases as well.

image postion: To much to type IMO.

@Volker

Text around an image can't be done yet, but I'm thinking of a good 
way to support that. In HTML it will be done with a table, but how 
should it be expressed in a document format?

About *bold*, ~italic~, -strike- and _underline_, maybe it would 
be a good idea to introduce a new paragraph level state change called 
=magic (I got the idea from the vim editor). If the writer type:

=magic


then the short form of bold, italic and so can be used. If the writer 
type:

=/magic


we're back to the default character level state changes: [b], [i], 
[s] and [u]. Isn't that a good idea? :-)

I've updated my NicomDoc specifikation: http://home.tiscali.dk/john.niclasen/NicomDoc.html

(NicomDoc is a working title, and I just specify this format, because 
I need to make a lot of specifikation and documentation myself in 
the future, and I don't think, MakeDoc suits my needs. I've also 
looked at make-doc-pro, and it's close to what I need. I hope, we 
can specify one open format, that will suit us all.)

I've also updated my comparison of NicomDoc vs. MakeDoc2: http://home.tiscali.dk/john.niclasen/NicomDoc-vs-MakeDoc2.html

LOL! I keep typing "specifikation", it's of course "specification".

specifikation
 is danish

paragraph level: Hmm... I don't like it much. Not simple-user compatible. 
Any why provide two ways of saying one thing? I know Rebol has it 
too but this doesn't make things simple.

Yes, that's a concern. hm

It's difficult to judge finally, before I have a working formatter. 
Some things look good in theory, but fail in practical use. One thing 
is for sure, writers should be able to write anything, any combination 
of characters, and get the wanted output in an easy way.

Take LaTeX than.

make-doc and make-doc-pro is for simple to medium complex documents. 
Not more. I don't think MDP is a replacement for a word-processor, 
DTP program or something near like LaTeX.

Good points!

I have to agree... I use MDP for three reasons: It's speedy, it's 
fast and it's not slow. :-)

These are two :-))

:-))

...but maybe he meant speedy in how you can prototype your docs and 
not slow as not slowly generating result :-)

Yes, tools like MakeDoc are about focusing on content, not style. 
It's great if we have a *way* to do more complex things (extension, 
manual tag insertion, etc.), but they shouldn't be a priority.

Looking at MakeDoc2 a bit closer I note that TOC expansion occurs 
during the second parse (HTML emit), meaning that  a 'scan-doc will 
not return all the data required by other emitters. I don't believe 
it should work this way.

The first pass generates a block structure that can be scanned by 
every emitter to get all headings etc. So, after scan-doc the info 
is there but not the build-up TOC.

Exactly, which means each emitter then has to generate a TOC and 
number the section headings - this content manipulation should not 
be the concern of each and every emitter! ;)

It'll still have to occur after the first pass, natch -- 'tis a pass 
unto itself.

The thing is, that the TOC might look very different depening of 
the output format. A TOC for LaTeX is just one command, for HTML 
you need to insert numbering as plain text etc.

Some emitters want numbers others letters or mixes of both. It all 
depends and that's why the job is left to the emitter.

Good points,. Robert. And some may need to defer it until nearly 
the end of Phase 2 because they need actual page numbers.

OK, makes sense now. ;)

How about this for an obvious enhancement: the ability to href an 
=image (i.e. image + URL)

good idea, Ashley...the Devcon page maker has this in it, if I understand 
what you mean.

Can you give me an example?

You want to use =image with an URL? That's possible.

update: I just extended make-doc-pro to support forms. Looks like 
this:

Test of Form Dialect in make-doc-pro

=toc

=options debug

===Introduction
This file test the form generation dialect.

\form test.cgi
	cgi-bin http://localhost/cgi-bin/

	; same-width with fields & buttons
	same-width left [
		field "Name1"
		field "Name12" 10
		field "Name123" 10 20
		field "Name"
		radio "R1" [Robby Linna Bunny Blacky]

		btn-enter "Abschicken"
		btn-cancel "Abbrechen"
	]

/form

You want to use =image with an URL? That's possible.

For example:

	=image %myimage.png http://mysite.com


click on the image to go to the site. I don't think the MD2 standard 
currently supports this.

I did wonder if that was what you meant...a good suggestion.

(and not hard to do at that)

I would suggest something else:
=url http://www.mysite.com%image.png

It's a URL you want to specify, not the image.

I never like to do to many arguments in Make-Doc, but what of Alt 
Text...

=url http://www.mysite.com%image.png Alt Text, but code sensitive 
parts of the line are getting more numerous...

Re. Forms, as discussed briefly, I have a different vision for forms 
-- primarily as I think we have a different end user in mind.