Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've been comparing these things (ascii markups) lately, mainly because I'm writing software to support an organization with a long history using not one, not two, but three unique ascii markup conventions. Could these somehow be translated into a more or less standard one, and gain the freedom of output provided by e.g. Pandoc?

What's depressing to me -- and my depression is not alleviated by reading Skriv's syntax -- is how similar they are and yet how none of them deal with the many kinds of typographical formatting that are routine in printed books.

For one simple example: Poetry. (Case in point: [1]) People who publish poetry expect as a matter of course to control their line-breaks and their indention in support of their meaning, and to center lines of text. Only AsciiDoc ("verse" block) and Skriv support literal line breaks (outside of monospaced code blocks). I don't know of any of the ascii markups that support centered text, or controlled indents.

Another simple example: Drama, play scripts. (e.g., [2]). Act and Scene titles are centered; character names are often small-cap (try commanding small-cap in any ascii markup); in older published plays it is common to have entrances and exits right-aligned: "[Exeunt" in the right margin. Both verse and drama (not to mention legal documents) often have reference line-numbers in the right margin, on the same line as left-justified text.

Quoted correspondence often has dates and signatures right-aligned. AsciiDoc supports right-alignment only in the single case of the citation of a block quote. I don't know any other text markup that allows even that much.

In short, the couple of dozen extant markups are solving the same limited range of problems over and over for no better reason than general NIH, while ignoring the much wider gamut of published formatting.

[1] http://carl-sandburg.com/chicago.htm

[2] http://www.shakespeare-online.com/plays/macbeth_3_1.html and this is a wretchedly ugly example but look at the source! It's a TABLE!



You nailed it! I am a typographer by profession, and I know exactly what you mean. The trouble with most light-markup languages is indeed their very limited document model and set of node types — basically an html subset, just good enough for blog posts, and, at best, source code documentation.

I’d rather take inspiration from something like the Chicago Manual of Style: we need many types of lists; more levels of headings/sections and control over their formatting; plates and figures; there are many types of “blockquotes”, etc. Poetry and drama are just some of the more difficult cases. How far must one go, or what, for example, should we do with things like Apollinaire’s [calligrames](http://en.wikipedia.org/wiki/Calligrammes)?

As for your use cases: Besides AsciiDoc’s “verse” and Skriv’s support for literal line breaks, z.m.l. too takes these into account. For drama, there is Fountain.io’s domain-specific light-markup for screenwriting.

Very interested in your research and software. Do have a look at my (premature draft) light-markup [concordance}(https://github.com/rhythmus/markdown-resources/blob/master/l...), and feel free to add.


It's a TABLE!

I believe that's because it's a table semantically. I mean, look at it - three columns, fixed width, sometimes columns 1 and 2 merge together. That's a table any way you look at it.

I never understood people's fear of tables - they're awesome, they're easy to control the lay out of, browsers support them just fine, they can be as flexible as you want.

And if you feel sick every time when you type a <table> tag, you can specify them in CSS nowadays.


I think you misunderstand the goal of light markup languages like that. If you're interested in typography, you'd probably convert the markup to LaTeX. If you're interested in poetry or drama, you'd probably also convert to latex and use its packages. E.g. the (now dead) deplate converter works this way to allow markup of drama/scripts (e.g. http://deplate.sourceforge.net/Input.html#hd006005) etc.

IMHO the main problem is that markdown, which serves its purpose well but isn't well thought out as a markup language because of too many ambiguities, dominates the "market".


I quite like the generality of scribble syntax [1]. It is in the spirit of LaTeX, but is programmable in racket/scheme. The downside is that it is implemented pretty much for the purpose of writing racket documentation, with little/no support for other programming languages or output formats.

[1] http://docs.racket-lang.org/scribble/


Thanks for the pointer. I find the documentation pretty resistant to a quick lookover, read "The Scribble Syntax at a Glance" and be afraid.

However I see that it does support centered text, intentional line breaks and -- unique among LMLs to my knowledge -- right-aligned text spans ("margin-note" command) which could be used for poetry line numbers, stage directions, and sidenotes.

Now... if there was a Pandoc reader for it...


The thing is a scribble doc is not markup. It is code. (This is one of the beautiful things about lisp.) So if you want the "syntax", all you need to know is this -

    @animal[bowow "meow"]{Various sounds animals make}
translates to

    (animal bowow "meow" "Various sounds animals make")
The rest are just libraries of code that render these resultant data structures in various ways. When writing documents, this programmability is very powerful.

If you don't need too much programmability, but would occasionally like to have it, "org mode" on emacs is fantastic. (I wrote my Ph.D. thesis in org mode and I also use it to track tasks.)


Another link posted recently that's based on Racket - http://mbutterick.github.io/pollen/doc/





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: