Novelang-0.8.0 released!

Latest release of Novelang can be downloaded here. Coolest features of this release:

• Directory listing.
• New --port option for HttpDaemon.

See release notes (in the "Status" chapter) for details.

Roadmap

Priorities are:

1. Bug fixing.
2. Documentation.
3. Error handling.
4. New features.

Stability is the key feature for adoption. Novelang will grow slowly, and won't advertise a lot until all features I think necessary are present. I don't want to harass my testers with bugs or missing features I already know about. Improvements on short term:

• Report location on every error.
• Try to recover on unmatched delimiter (like missing closing parenthesis).
• Document some tricks.

Requirements for 1.0:

• Better URLs: inside paragraphs, alt and text properties.
• Fix potential punctuation problems.
• Lists, ordered and unordered.
• Images. May turn to an infinite feature list -- be careful!
• Accolades and angled brackets (used for footnotes and index entries).
• Identifiers. These are needed for generating table of content.
• Bold, small caps, superscript, subscript, a few levels of headers below section.
• "Beautiful" PDF generation with a look inspired from Manning's books, table of content, index and so on.

After release 1.0 there are two different paths to follow in parallel (will depend on feedback I suppose):

• Improve content generation.
• Open Novelang to other developers, as an embeddable / extensible software component.

Content generation improvements include:

• Identifier-based inclusions.
• Multi-document output (useful for generating web sites with several pages).
• Resource scan for automatic copy in batch mode.
• Some optimizations for speed / memory consumption.

Componentizing Novelang means:

• Remove dependency to Jetty and rely on pure Servlet API.
• Pluggable tree manipulation functions. By now such a mechanism is used internally but it deserves to get open. Would require some Generics to support custom Environment class.
• Extensible grammars. Thanks to ANTLR 3.1 it will be possible to write a grammar reusing parts of an existing one. So developers could writer their own additions to Novelang's standard grammar, while ANTLR performs all consistency checks. By the way, making a grammar evolve is not a quiet game.
• Extensible grammars mean redefining token list.
• Component weaving with Guice. Guice is the coolest way to assemble components which are, basicall, functions.
• Configurable escape codes, and whitespace triggers.

Novelang as component can be advertised through some plugin for a tool like Maven or Eclipse.

Directory listing

I just finished the directory listing feature and it seems terribly addictive. Let's say you started Novelang HTTP Daemon from $NOVELANG_HOME. The sample directory is full of samples. Given a URL like http://localhost:8080/samples, your browser displays a page listing all Novelang documents, including those in subdirectories.

..
samples/
 samples/book.html
 samples/broken.html
samples/scanned/
 samples/scanned/book.html
 samples/scanned/file1.html
 samples/scanned/file2.html
samples/scanned/sub/
 samples/scanned/sub/file3.html
samples/showcase/
 samples/showcase/showcase.html
 samples/simple-structure.html
 samples/unicode-1.html

All lines are links to subdirectories and documents. There is also a link to the parent directory, while it's not a parent of the content root itself (for security reasons). For a consistent URL scheme, a directory listing ends with "/". In the example above, the browser is forwarded to http://localhost:8080/samples/ (note the trailing solidus). There is another trick required by Safari. Safari doesn't take the MIME type of the document in account, just the resource extension. No matter how loud you say "it's HTML, stupid" it tries to download the file instead of displaying the page. So Safari is handled as a special case which is redirected to a URL like http://localhost:8080/samples/-.html. Yeah, it sucks. I chose the "-" name because it's not a valid filename so it won't conflict with document sources (it's perfectly legal to have a "index.nlp" file). There are many possible improvements:

• Show directories containing no Novelang documents in a dimmed color (not showing them at all could be confusing).
• Add a link to every supported format (first, PDF).
• Add breadcrumbs like / > samples > served
• Add some metadata like number of files and the date of the last modification.
• Display files in the same directory on several columns.

Novelang-0.7.0 released!

Version 0.7.0 is hot! You can download it here. It comes with a complete redesign of literal and character escaping.

• Literal blocks are still here, much improved as they support any character on the inside.
• Hard inline literal, corresponding to "technical" text inside plain text, like code citation. Renderers will use monospace font. Every character will appear as it is.
• Soft inline literal works the same way hard inline literal does, but it should not be rendered in a different manner than casual text. Soft inline literal is a convenient answer for supporting almost any character and disabling standard formatting that occurs with punctuation, while avoiding conflict with other style delimiters.
• Character escape is a last-resort option for displaying characters used as delimiters for one of the literal forms described above.

There were previous posts describing how this should work. During the implementation, there were minor adjustments so refer to the documentation.

Character escaping

I just fixed a few bugs, now literal form supports nested less-than / greater-than signs, except if there are three greater-than signs in sequence at the beginning of a line. Very sweet (at least for Novelang documentation) to make this a correct literal block (starting with '<<<' and ending with '>>>', both on the beginning of the line):

<<<
<<<
 >>>
>> >
>>>

This dramatically reduces the need for character escaping. Of course there is always a weird language to quote with three greater-than signs at the beginning of a line. And there may be other weird characters in a non-supported encoding. So we're hitting character escaping problem again. In the refactoring-characterescape branch I already pushed new character escaping based on the tilde '~' character but having a non-symmetrical delimiter makes the document source much less readable. Of course this is because I'm using character escaping as a workaround, until I implement better literal. But that unreadable stuff is like a warning that tilde character is inappropriate. And I realize that it's commonly used in programming languages, so it should be escaped in literal. Gets tedious when you copy-paste from your favorite programming language. As a Mac user I'm a bit stuck to their keyboard layout but I think that left and right pointing double angle quotation marks (don't laugh, it's official Unicode name) is ok. Instead of this:

~escapecode~

I'm about to switch to this:

«escapecode»

The interest is obvious when there are several escaped character to juxtapose:

«escape1»«escape2»«escape3»

is better than

 ~escape1~~escape2~~escape3~

On a Mac AZERTY keyboard the two characters are obtained with Alt-7 and Shift-Alt-7. There must be something similar on other platforms (Windows, QWERTY). Anyways this doesn't have to be used often so it's ok to use a weird character that doesn't appear in common text or programming language. It would be then possible to document Novelang correctly by giving a sample of literal like this:

<<<
<<<
Some literal here.
«greaterthan»«greaterthan»«greaterthan»
>>>

Or even like this:

<<<
Escape character like this: «lpdaqm»escapecode«rpdaqm».
>>>

Of course lpdaqm and rpdaqm stand for "left (respectively right) pointing double angle quotation mark". I prefer to avoid acronyms but this name is really too crazy.

Impressive XSL-FO resource

I was looking for how to make appear the name of current chapter in a PDF header. This is called "running header". Found Dave Pawson's site on XSLT, DocBook, and Braille. The FO section contains very serious stuff pretty above all other tutorials! The running header requires no trick. It's a standard FO feature: define a marker corresponding to current chapter title / whatever (fo:marker) and retrieve it from the header definition (fo:retrieve-*).

Novelang-0.6.0 is there!

Now you can do all sorts of amazing things with stylesheets, as explained in the documentation. There is also a nicer default stylesheet for PDF. Check out PDF version of Novelang documentation!

New feature: selectable stylesheets

I just checked into GitHub the code for selectable stylesheets. Until now, a Novelang project could define its own stylesheets, using custom stylesheets. While Novelang can render PDF and HTML with its own, built-in stylesheets, every user probably needs to define his-her own ones. When rendering a document, Novelang attempts to find appropriate stylesheet:

1. In the directory given by novelang.stylesheet.dir system property, if defined.
2. In a style directory under the directory from which Novelang was launched (corresponding to user.dir).
3. Inside Novelang-x.x.x.jar under the /style directory.

"Appropriate stylesheet" means a stylesheet corresponding to the MIME type of requested document: pdf.xsl for a PDF document, html.xsl for a HTML document. That was not flexible enough because the same document of the same MIME type may deserve multiple renderings, like "miser printing", "visually impaired" and "tree-killer". That's where selectable stylesheets come to the rescue. With selectable stylesheets, you give the name of the stylesheet to use. This can be done at query level, or at book level. Let's say this is your project layout, with two stylesheets under the style directory:

/
  book.nlb
  chapter-1.nlp
  chapter-2.nlp
  style/
    html-quick.xsl
    html-beautiful.xsl
    pdf-beautiful.xsl

After launching Novelang HTTP daemon, you can use the stylesheet query parameter to override any other stylesheet name:

http://localhost:8080/chapter-1.html?stylesheet=html-beautiful.xsl

Please note the html-beautiful.xsl path is still relative to the directory containing custom stylesheets! Another place to set stylesheet names is the Book file. Since a Book doesn't know how it will be rendered, you can define a stylesheet for multiple document MIME types. The book.nlb would look like this:

mapstylesheets 
    $html=html-beautiful.xsl
    $pdf=pdf-beautiful.xsl

insert file:chapter-1.nlp

insert file:chapter-2.nlp

I've not tested subdirectories yet but they are supposed to work. Keep in mind: they will be relative to the directory containing your stylesheets. Supporting multiple stylesheets is a necessary step before provinding nice built-in stylesheets to be tried with documents of your own.

Links on typography and characters

Wikipedia Punctuation: links to punctuation, plus interword separation, general typography, uncommon typography. Ordinal indicator Superscript Superior letter Others XML character entities Unicode character search

Some ideas for Novelang syntax extensions

Just some ideas here and here.

Here is some text ++- striked out -++.

Oh, yeah, looks like the ''++'' radix is powerful as it cleanly expresses strike. It can be composed with other characters, and supports symmetrical delimiters! I like the plus sign for designating the strike family, as it is a vertical line (figuring some character) with an horizontal strike.

Here we get ++= double strike =++.
Here we get ++$ highlight one $++.
Here we get ++£ highlight two £++.
This is a sample of ++/ oblique strike /++.

The same approach fits for underline. The _ (low-line) character is fine for underline (that was its purpose on mechanical typewriters).

Same for __- underlining -__.
So we have double __= underlining =__.
So we have waved __~ underlining ~__.

Novelang syntax already uses a low line for the "silent end" of interpolated clauses. In order to keep a strong meaning to the low line maybe we should revisit the silent end.

New silent end for interpolated clauses -- like this -<.

And now I've found what double circumflex accent is good for: small caps. Small caps sometimes carry a strong meaning, like for quoting a shouting person, or for names for which case matters (like Charles De Gaulle).

And this is for ^^ Small Caps ^^.

Talking about circumflex I was thinking about superscript those days and according to my researches superscript text is always the last part of a compound text, before a space or a punctuation sign.

Like: 2^nd.

Subscript will work the same way with a single underscore. Ayways I'll have to think a lot about all of this. I must take care of not losing the focus on content-oriented text and not invent a messy markup.

Encoding(s)

Attempting to run Novelang-0.5.0 the way the documentation said (java -jar Novelang-0.5.0.jar), I discovered that some characters (especially those with accents) were not rendered as they should. As I'm working on MacOSX I shouldn't have been surprised when reading the system properties dump:

  file.encoding = MacRoman

I couldn't see the mismatch under my development environment, as it was "kindly" (and rather stealthily) forcing the file.encoding system property of a new process to encoding I did set for editing my files. If you, happy early adopter, hit such a problem and were to shy to post on Novelang User list, you've got to try this:

  java -Dfile.encoding=ISO-8859-1 -jar Novelang-0.5.0.jar

By now Novelang expects all files to be in ISO-8859-1 (aka ISO Latin 1). This is defined as a constant somewhere, and passed through method calls. I thought this would make Novelang should be insensitive to the file.encoding system property but obviously I missed something. No doubt I'll find what sooner or later, but this lead me to more interesting reflexions. File encoding must be known to convert the 8-bit characters from a file to Java's internal 16-bit Unicode characters. Novelang grammar defines very precisely the characters it accepts: a subset of ISO-8859-1. But it doesn't mean the document source file has to be encoded this way! The "é" character also exists in MacRoman encoding, so file.encoding property must be taken for what it is: just a hint to read Unicode characters from a stripped-down format. This lead me to the following conclusions:

• Novelang grammar defines every supported character, no matter which encoding as they are defined in Unicode. This guarantees a lot of fun with Greeks, Germans, Russians...
• If one encoding for all files is the option then the file.encoding system property provides the simplest approach. This is current option (because of a bug preventing ISO-8859-1 to be forced as default).
• Per-file encoding would be a must. A Book function would be ok, telling "from now on, read Part files with encoding xxx". A HTTP query parameter could provide such a hint when previewing Parts with special encodings in a Web browser.

I strongly recommand this excellent paper about character encoding and Unicode, by Joel Spolsky:

Novelang-0.5.0 is there!

I just posted about this first release on a French mailing list gathering friends and former colleagues. I received valuable feedback and ideas.

1. Factory templates: come with nice PDF / HTML templates. 
2. Split output: multiple HTML files from one single Book.
3. Write something like a roadmap somewhere (this is how this post looks like this, right?).
4. Links inside documents.
5. Point out differences with other wikis.

Nice factory templates mean ability to switch between stylesheets. By now the stylesheet is determined by the extension (MIME type) of requested document. Split output means adding some metadata:

1. On the stylesheet itself. Does it support split output? 
2. On the document to be rendered: it's nice to know where it is located inside the list of all subdocuments for generating a navigation bar.

How to log in on Sourceforge for website maintenance

SourceForge documentation is hard to find. So here is the link: http://sourceforge.net/docman/?group_id=1 And that's what I'm looking for most of time, for website maintenance:

ssh -l caillette shell.sf.net
cd /home/groups/n/no/novelang/htdocs

Aside of this it's nice that SourceForge supports OpenId. But it works in parallel with Unix account that must still be used for ssh sessions.

Novelang project first-rated on Google!

"Novelang" also appears to be a word of Tagalog, the principal language in Philippines. It seems to mean "novel".

Versioning

Now I'm working hard for a first public release. I don't expect many people to use Novelang because it lacks many features and is still subject to change, but "think big, start small". Here comes the question of versioning. APR versioningprovides a good conceptual framework for thinking about about to set version numbers:

Versions are denoted using a standard triplet of integers: MAJOR.MINOR.PATCH. The basic intent is that MAJOR versions are incompatible, large-scale upgrades of the API. MINOR versions retain source and binary compatibility with older minor versions, and changes in the PATCH level are perfectly compatible, forwards and backwards.

Novelang is not unlike a code library: you provide sources (documents) and I deliver software interpreting it. Specification of the software may change, including breaking backward compatibility (that I'll try to avoid at least because of my own Novelang documents). But wait, there is more. Since the Book feature is checked in, Novelang becomes a platform running arbitrary Java code that foreign developers may plug in. Same compatibility problems occur on a different dimension. How to reflect changes on those two dimensions? Should I mix them just telling if backward compatibility is maintained for both, as users are just users, whether they are developers or text writers? I don't need to find an answer by now but the solution may not be obvious so I have to start thinking on it by now. Do you know about other tools having the same problem?

Book feature just started working!

Oh yes I just committed the Book feature and it looks good! A book file looks like this:

insert file:relative/path/part1.nlp

section
  This Section was defined from inside a Book file!

insert file:part2.nlp

This means: "fetch a pair of Part files and define some Section between them". After launching the HTTP Daemon you can see resulting document with that URL: http://localhost:8080/samples/book.html. First it attempts to load a samples/book.nlb file ("nlb" like NoveLang Book). If the file doesn't exist, it attempts to load its .nlp counterpart ("nlp" like NoveLang Part). If the .nlp file doesn't exit then the preview fails with an error message. The syntax for Book files is easy to expand, as functions like section or insert are not defined inside the grammar. Instead, they are Java classes that receive arguments and apply to a document tree. For Novelang, a Book is made of function calls. The general form of a function call is a function name, then a URL or an identifier or a paragraph body (all optional), then an unlimited number of arguments wich can be identifiers, or words preceded with a dollar sign ("$"). Here is the formal definition as an ANTLR grammar fragment:

functionCall
  : word 
     (   smallBreak url 
       | smallBreak headerIdentifier 
       | WHITESPACE? SOFTBREAK WHITESPACE? paragraphBody
     )?
    ( mediumBreak valuedArgument )*
  ; 

valuedArgument
  : ( PLUS_SIGN? blockIdentifier )
  | ( DOLLAR_SIGN word )
  ;

In order to make the grammar simple, there must be a line break between the function name and paragraph body. This constraint is ok as it makes the Book file more readable. A paragraph body is the same as for a Part: a sequence of words, punctuation signs, and blocks made of quotes, parenthesis, square brackets and interpolated clauses (all can be nested). A header identifier is a reference to some block of text defined elsewhere (more on this here). The dollar-hinted words indicate some other options. On the Java side, functions are defined by implementing the FunctionDefinition interface. This interface defines the contract for instantiating a FunctionCall which captures all the values for a given call (like file:part2.nlp parameter value in the example above). The FunctionRegistry knows FunctionDefinitions by their names. As a Book evaluates itself, it receives the result of the parsing of a Book file: basically an Abstract Syntax Tree with FUNCTION_CALL nodes. For each nodes it attempts to get a FunctionDefinition instance, then a FunctionCall object. The FunctionDefinition checks parameters sanity and consistency, for a fail-fast approach. The FunctionCall operate on an immutable tree-like structure called Treepath. A Treepath indicates the relative position of a Tree inside another "bigger" Tree. It solves the problem of changing the value of an immutable Tree (by creating an evolved copy) while original Tree is the child of some other immutable Tree. Immutable objects make easier to get safer and cleaner code. Before implementing more functions, I'll play a bit with the insert and section functions and investigate error cases like having a broken Part file.

Images

My goal is to not introduce syntax constructs into Novelang for every need, but handling images with paired delimiters quickly becomes a mess. So image: syntax is fine but it collides with what a plain Paragraph can be made of. Let's twist it a bit using a double colon for now.

image::path/file.ext

As with URLs it seems more readable to force image declaration to start at the beginning of a line. The all-on-the-same-line requirement comes with the same advantages: it's easy to add metadata.

image::path/file.ext "title"

There are several ways to reference an image: the image itself for displaying it, or its name. Many document have textual references to images (like Fig. 5). Numbering must be automated, and text must reference images through a symbolic name. It's a clear need for identifiers. Defining identifiers works the same as for Paragraphs:

  \\image-identifier
image::path/file.ext "title"

Referencing the image is done with a new image-ref:: keyword, that should appear at the start of a new line, too:

Have a look at
image-ref::\\image-identifier
.

Ok I'm not happy with the full stop coming on its own line but I'm just trying to be honest so don't hit me. Depending on numbering scheme this should translate to something like:

Have a look at Figure 5-12.

Image display can happen through a reference, too:

image::\\image-identifier

With all that in mind, here is how to use images in big documents. Define one Part file or more with all images, then reference them as needed. The Part files containing images may define Sections with their own absolute identifiers corresponding to some themes or categories, and all images inside the Sections have a relative identifier. Another advantage of having all images in separate files is to get an overview for free.

More on identifiers

Since I've been blogging on identifiers something came to my mind. There are absolute identifiers (for Chapters and Sections) and relative ones (for paragraphs). The syntax should reflect this. What about :

  \\absolute-identifier

  \relative-identifier

The reverse solidus (well-known of Windows users) is convenient for expressing path-like structures, while not conflicting with the solidus used in URLs. A relative identifier requires an absolute identifier. For a Part like this:

== Section
  \\section-identifier

  \paragraph-identifier-1
Blah. 

  \paragraph-identifier-2
Blah blah. 

  \paragraph-identifier-3
Blah blah blah. 

Here is a valid reference to the paragraph:

\\section-identifier\paragraph-identifier

The absolute identifier may be carried by the context. As described in the Book post, only some Paragraphs in a Section may be included so referencing the Section is a way to define such a context.

expand \\section-identifier
  \paragraph-identifier-1
  \paragraph-identifier-3

Ok the syntax has slightly evolved since but you get the idea. The reverse-solidus based notation looks good to me. Double path separator for an absolute path is a well-known pattern (URL spec). I like the idea to ask a bit more work for an absolute identifier as they should be used carefully, in order to avoid global namespace pollution. With that syntax we now support an uniform relationship model between Chapters, Sections and Paragraphs.

Unstyled inline litteral and collateral damages

I'm not satisfied with the need for escaping characters one by one in situations like an acronym. There should be whole blocks of text looking like normal text, but disabling most transformations. Could be like:

I want my ``T.L.A``.

The double grave accent makes the text inside quite readable but there is a consistency issue with the rest of the syntax. The blockquotes use double square brackets and the block litteral use a triple square brackets and it looks good.

To keep consistent, the unstyled inline litteral must use single grave accents and the code-like inline litteral use double grave accents ("plus one" rule).

So rewriting examples in the previous post gives this:

I want my `T.L.A.`
This is double slash ``//`` delimiter.

I'm starting to like it because unstyled inline litteral is just eye candy while codelike inline litteral has a stronger meaning that is better carried by thicker delimiter.

Novelang syntax for Parts

I haven't documented the Novelang syntax yet but there are already plenty of things to change. WikiCreole's reasoning and Markdown give a great start for yet another discussion on Wiki markup.

In this document, character names refer to Unicode specification.

Headings

The chapter should be a double equals, and the section a triple one. There is a single character to know about and it's dedicated (asterisk are used by bold and unordered lists, see below). And it's eye-catching without the crippling effect of many asterisks.

== Chapter

=== Section

This makes the markup "scalable" in the sense it becomes easy to support a subsection level (though it may reflect that Parts are becoming too complex).

Identifiers and Tags may decorate Headers as they appear just below Header declaration (one linebreak away). Header identifiers are prefixed by an ampersand. Tags are prefixed by a commercial at.

== Chapter
  &identifier @tag

Paragraphs

Paragraphs are just lines of text. They are delimited from the rest by two linebreaks or more (aka hardbreak). They support identifiers and tags immediately above (one linebreak away no more). Paragraph identifiers are prefixed with a plus sign immediately followed by a commercial at, to indicate they don't work the same as Header identifiers, which are global.

This is one paragraph, continuing
on this line.

  +&identifier
This is another paragraph with an identifier.

Words are any sequence of letters and numbers. There can be a single dash between two letters or number. Apostrophe is a word delimiter.

C'mon, just a two-worded word!

There are some combinations which require character escaping, like acroynyms with dots. That looks messy but trying to turn this into a generic case seems to make things even worse.

I want my T~.~L~.~A (Three-Letter Acronym)!

Character escaping

I've been discussing character escaping and now I think that there should be no difference between single and multiple character escape, in order to avoid confusion. 

Ampersand: ~&~
O and E ligatured: ~OE~ 
Tilde: ~tilde~ 

Backslash character was an option but I like the tilde character as it carries the meaning of something linked to the rest.

Inline litteral

Inline litteral requires a delimiter with reduced visual cripple, available on most keyboard, generating minimal conflict with casual use. The grave accent (backquote) is such a gem.

 This is double slash `//` delimiter.

Tilde was a serious candidate but it has a better meaning for escaping, while the grave accent looks more like quotation. 

Bold

Double asterisk looks good and is consistent with italics' double slash. 

This is **bold**.

Subscript and superscript

A delimiter made of a single character is more concise than a double one. As it takes less visual space it reflects semantically weaker meaning. Circumflex means superscript and low line (underscore) means subscript. 

L^A^T_E_X is expected to render as L^AT_EX.

Supporting subscript and superscript will be a mess because wether it is attached to a word or not does matter for the rendering.

Links

Often I got annoyed when copying an URL in the middle of the line. Now I'm reinventing a better world and I want to force the URL to appear at the beginning of the line. 

Many Wikis have messy syntax for URLs / URIs because of related title and text. This can be avoided by some contextualization like the quotes immediately following an URL become the text to show. Same for the link title that could be a parenthesized block.

The URL here belongs to current paragraph:
http://novelang.sf.net "Go there" (Novelang home page)

Then HTML output is expected to look like this :

The URL here belongs to current paragraph: Go there

If the quoted text really should appear as quoted text then a line break cuts it away from the URL while keeping it inside the paragraph.

URLs are an easy case as its starts with a scheme ("http:" or "file:") but URIs are harder to handle. They are left out for the moment.

Lists

Unordered lists have items starting with an asterisk.

Ordered lists have items starting with a number sign.

Sublevels could repeat the list item sign but a level 2 unordered list item marker would clash with the bold marker. The trick is to use indentation.

* Item 1
  * Item 1.1
  * Item 1.2
* Item 2

And it goes the same for ordered lists. Some text editors recognize intentation and perform wrapping under the first indented character.

Blockquotes

A pair of angled brackets look fine for defining blockquotes. They must be on the start of the line and alone on the line where they appear.

<< 
This is a blockquote. 
>>

I try to avoid closing delimiter whenever possible, but the alternative approach, which is to use a special character at the beginning of a paragraph, would require to edit each paragraph when pasting foreign text.

Litteral

Litteral is text appearing the same as in the Novelang markup. It appears inside triple angled brackets, opening and closing brackets must be on the very beginning of the line and their trailing space is not rendered. To render triple angled brackets at the beginning of a line, character escaping is required. But such combination is quite rare and shouldn't be a hassle.

<<< 
This is litteral, 
  preserving indentation.
>>>

The need of a closing delimiter is a no-brainer here.

Tables

As the Book feature supports including other file's content there should be a function to read a CSV or whatever and display it nicely. So we don't pollute the markup with a feature bloating other wiki's syntax with more and more complex style stuff.

Features I'm happy with

Interpolated clauses must be more than a special character like —. They must be declared as blocks (with opening and closing), so rendering can insert non-breakable spaces after opening dash and before closing dash. And the closing may be hinted to be not-renderable.

Interpolated clause delimiter is double dash. A dash then a low line define a non-renderable ("silent") closing.

Interpolated clauses -- like this one -- do rock.

Silent ends rock, too -- yeah-_.

Parenthesis, brackets and quotes are blocks, too, using conventional character.

(parenthesis) [brackets] "quotes"

Italics use double slash delimiter. A double character looks "big" so it refrains from overuse.
This is //italics//.

Punctuation signs come with no surprise.
Question mark ? Exclamation mark ! Colon : Semicolon; Comma, Ellipsis... Full stop.

Comments. Because of italics, the double slash made popular by Java and C++ is not an option. In order to reduce confusion, corresponding slash-asterisk combination cannot be used because for most people, they are both parts of the same set of conventions.
So line comments starts with a double percent sign, and block comments are delimited with double accolades.
%% Single-line comment.

{{ Block 
   comment }}

Single accolades may have a special meaning but they are free for now.