Novelang
Laurent Caillette
J'ai la joie d'annoncer la disponibilité de la première version
officielle de Novelang, générateur de documents à partir d'une syntaxe
Wiki.
C'est un projet issu de multiples expériences en matière de rédaction
de documents. Quel est l'outil le plus efficace pour écrire un texte
formaté ? J'en suis toujours revenu à l'éditeur de texte (Smultron,
UltraEdit...). La syntaxe de type Wiki représente le nirvana dans le
domaine à condition qu'elle reste simple. Hélas les Wikis du marché se
focalisent sur les aspects collaboratifs, au détriment de certaines
exigences de mise en page. En face il y a bien sûr LaTeX mais le
ticket d'entrée est généralement dissuasif. Il y a donc une place pour
un outil comme Novelang.
Novelang est le dernier avatar d'une suite de générateurs réalisés par
mes soins, d'abord avec Forrest, puis avec un assemblage Xilize +
Flying Saucer. Devant tous les problèmes d'intégration posés par ces
outils j'ai fini par être convaincu de la nécessité de mieux maîtriser
la plomberie entre un parser généré à partir d'une grammaire formelle
et le renderer de PDF.
Novelang définit clairement la séparation entre les fichiers de
contenu (Parts) et les fichiers de structure (Books). Ces derniers,
optionnels, permettent d'agréger les fichiers de contenu.
Novelang utilise un parser (généré avec ANTLR v3) pour générer un AST
(Abstract Syntax Tree) intermédiaire. L'AST peut être enrichi et
remodelé de différentes façons, puis il est passé à un renderer pour
produire le document final. Un renderer particulier repose sur des
XSL, ce qui permet de définir des modèles de HTML ou de PDF (avec
FOP).
En termes de conception je suis particulièrement fier de la façon de
traiter les fichiers Book. Un fichier Book contient une suite
d'instructions genre :
insert file:my/parts $recurse
Ces instructions ont une syntaxe unique. Le nom de la fonction est
mappé vers une class Java qui enrichira ensuite l'AST du document
final (ici avec toutes les Parts trouvées dans le répertoire
'my/parts'). La fonction en question reçoit et renvoie un arbre
immuable. J'ai décrit le principe dans un article précédent.
http://groups.google.com/group/techos/browse_thread/thread/661e7a9c6bb2fbf4
Novelang fonctionne en mode démon ou batch. On démarre le démon à
partir du répertoire contenant les sources de documents et on affiche
le rendu dans un navigateur Web. Pareil en mode batch, en indiquant
les documents à générer.
Pour l'instant Novelang supporte une syntaxe assez réduite: chapîtres,
sections, italiques, quotes, crochets, parenthèses, incise,
paragraphe, citation, littéral, ponctuation, URLs, caractères
échappés, commentaires. Je discute des extensions possibles sur le
blog.
Dans sa version actuelle Novelang peut déjà générer des PDF de
plusieurs centaines de pages avec des temps de réponse qui se comptent
en secondes, et une typographie impeccable (espaces insécables et
sauts de lignes).
Certains abonnés de cette mailing-liste ne manqueront pas de signaler
que j'ai bel et bien créé un DSL. C'est vrai. Sans avoir affirmé que
les DSL portaient le mal en eux j'ai toujours prétendu que le coût de
leur mise au point dépassait les évaluations les plus pessimistes.
Disons que je commence à en avoir la confirmation.
Enjoy !
c.
Dominique Jocal
suggestion d'amélioration :
- mettre plus en avant l'exemple: son source, sa destination HTML (bon ok), sa destination PDF
- expliquer comment on fait du html monopage, html multipage, pdf continu, pdf avec saut de page...
- fournir des styles "de l'industrie" prêts à l'emploi (je sais c'est la partie pénible) : le style épuré sun javadoc, le style maven doxia au hasard :-)
questions:
1) wiki ("rapide" en hawaien) insiste sur la concision des instructions afin d'atteindre rapidité et reprise minimale. Ex:
h1. section de niveau 1 chez confluence
h2. section de niveau 2
ou bien
! section de niveau 1 chez tiddlywiki
!! section de niveau 2
Intuitifs, faciles à mémoriser, et on ne s'y reprend éventuellement qu'à 2 fois.
est ce que tes "cadres" ascii permettent d'atteindre cet objectif, par ex on n'a pas à mettre un nombre exact de tirets, qu'il se fout du signe utilisé, etc ?
2) comment prévisualise t on ? tu conseilles qqchose de rapide également ? (sur confluence, 1 clic sur bouton preview; sur tiddly, 1 clic sur bouton done)
3) comment fait on des liens entre pages ??? le core mechanism de wiki...
thx
Dominique Jocal
OCTO Technology
Inscrivez vous à l'événement SI de l'année http://www.universite-du-si.com
Dominique Jocal
Laurent Caillette
priorités finissent par s'éloigner complètement de ce qui était
envisagé au départ. Par exemple je pensais qu'une tâche majeure serait
la gestion du cache pour aller plus vite. Or, déjà que j'ai commencé à
pouvoir générer des PDF j'ai constaté avec bonheur que les
performances me suffisaient ! Bien sûr dès qu'on commence à rendre
publique ses réalisations, les priorités évoluent du tout au tout.
Je vais donc m'atteler à la tâche des feuilles de style prêtes à
l'emploi (ou en tous cas comme jolis modèles). Il faudra d'abord que
je trouve un moyen de switcher de l'une à l'autre, pour l'instant
c'est l'extension du document résultant qui détermine la XSL (bouh).
Le HTML multipage est dans la roadmap (cette dernière se distribuant
entre quelques posts sur le blog et un coin de mon cerveau, pour
répondre à Tom).
Pour l'instant il n'y a que deux niveaux de "headers" : chapître et
section. Le chapître est annoncé par '***' mais il faut que je le
change en '==', et la section par '==='. D'ici la version 1.0.0 je me
permettrai encore quelques modifications de la grammaire.
Pour la prévisualisation c'est simple : à partir de ton éditeur de
texte tu sauvegardes le fichier sur ton filesystem local (certains
éditeurs sauvegaredent automatiquement à la perte de focus). Tu
bascules sur ton navigateur et rafraîchis la page
http://localhost:8080/mydocument.html (ou .pdf).
Pour l'instant le mécanisme de liens se limite à une URL entre deux
sauts de ligne, ce dont j'admets la parfaite indigence. Je ne compte
pas supporter la syntaxe Wiki avec CamelCase, mais quelque chose de
plus générique et plus compatible avec une typographie civilisée.
Au niveau d'une Part, on pourra définir des identifiants pour les
chapîtres, sections, paragraphes, citations, URLs et images. Un
identifiant pourra être absolu, ou relatif pour un élément contenu
dans un autre élément doté d'un identifiant absolu.
Ces identifiants fournissent la base de deux fonctionnalités majeures :
1) Les inclusions partielles dans un Book. Par exemple : dans la
section dotée de l'identifiant absolu '\\machbro' je veux le paragraph
'\un' (notation '\\machbro\un'). Fonctionnellement ces inclusions
partielles sont très utiles dans certains contextes où on veut se
baser sur un texte qui contient tout ce qu'on note, et en choisir les
meilleurs morceaux. Mais ce sont les acrobaties XPath dans l'outil que
j'ai bricolé avec Forrest qui ont achevé de me convaincre de démarrer
Novelang. Au moins là je pourrai fournir de beaux messages d'erreur en
cas d'identifiant dupliqué ou non trouvé.
2) Les références internes. Certains textes, comme des textes
juridiques, se basent sur des renvois internes. Lors d'un ajout /
retrait d'article toute la numérotation se trouve décalée, la mise à
jour est infernale avec de sérieux risques d'erreurs. Les références
internes permettent d'inclure une référence sous la forme :
text-ref:\\keep-your-computer-shut
Ensuite le renderer se chargera d'afficher quelque chose de joli
(genre 'Artikel hundert und dreizig') parce que l'AST contiendra la
bonne information. Dans le cas d'un rendu HTML la feuille de style
devra produire un lien <a href="...">.
Un aspect intéressant des références est qu'on peut définir des
fichiers entiers d'images, URLs... et ensuite utiliser l'équivalent de
liens sémantiques.
Évidemment le support de ces liens doit tenir compte de la génération
multi-documents !
Pour la longueur des extensions je réalise avec stupeur que je n'ai
même pas tilté, alors que ça fait quand même un bout de temps que j'ai
remarqué que .java faisait plus de trois lettres ! Je me sens
d'attaque pour migrer vers :
.novelang-part
.novelang.book
Merci pour ces questions et commentaires tout à fait constructifs.
c.
Dominique Jocal
- porter en novelang un morceau de doc existant en doxia
- indiquer les gains que l'on obtient avec des comparaisons de métriques (essai/erreur/succès : temps de réponse mode aperçu vs géné doxia, quantité et lisibilité du texte : nb carac tags wiki-like vs xml) et des feature list (destinations disponibles)
conserve la simplicité de ton archi pour maintenir très bas le ticket pour ton partenaire qui l'intègrera à maven.
voilou back to biz