3 ms·
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 t
by fernly 12y ago
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 http://carl-sandburg.com/chicago.htm
[2] http://www.shakespeare-online.com/plays/macbeth_3_1.html 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!
- anon4 12y agoIt'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.
- rhythmvs 12y agoYou 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 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/lightweightMarkupSyntaxComparison.tsv https://github.com/rhythmus/markdown-resources/blob/master/l...), and feel free to add.
- sriku 12y agoI 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/ http://docs.racket-lang.org/scribble/
- fernly 12y agoThanks 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...
- sriku 12y agoThe 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.)
- sriku 12y agoAnother link posted recently that's based on Racket - http://mbutterick.github.io/pollen/doc/ http://mbutterick.github.io/pollen/doc/
- NaNaN 12y agoMuch like SexpCode: http://cairnarvon.rotahall.org/misc/sexpcode.html http://cairnarvon.rotahall.org/misc/sexpcode.html
- stewbrew 12y agoI 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 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".