La fonction propre() est le centre du moteur de rendu : pour passer d’un article contenant des racourcis spip à du html, il suffit d’appeler $apres=propre($avant).

Seulement voila, cette fonction est un vrai foutoir :-) un peu de reverse engineering s’impose donc.
Je pars de la version dans le cvs du labo. Sauf indication contraire, toutes les fonctions suivantes sont dans include/texte.php

• propre($letexte, $echap = false) : appels successifs de trim (pour dégager les espaces au début et à la fin), traiter_raccourcis et interdire_scripts
  l’argument echap est passé à traiter_raccourcis.

• traiter_raccourcis($letexte, $les_echap = false, $traiter_les_notes = 'oui') (230 lignes !)
  les_echap contient une liste des blocs à ne pas traiter (les blocs code, html ...) qui sont mis de cotés
  traiter_les_notes est un booléen pour pouvoir rappeler traiter_raccourcis sur la partie footnotes sans boucler

• récupérer la langue courante (et sa direction)
• si les_echap est vide, le remplir en appelant echape_html
• traiter les notes de bas de page (lignes 592 à 636)
• les raccourcis glossaire (643-656)
• les liens (662-671)
  • en passant, c’est là qu’on traite la typo à la volée (j’ai mis le temps à le trouver !)
• les tableaux (676-708)
• les listes : appel à traiter_listes()
• les autres raccourcis (lignes 721-771)
  • preg_replace avec des tableaux de regex en argument
  • bricolage pour mettre les p et /p au début et à la fin (les sauts ayant été remplacés par des /p p, il faut régler le cas des premier et dernier §).
  • bricolage pour les intertitres et hr (le preg précédent les remplace par des marqueurs pour pas s’emmeler avec d’autres regex)
• réinsérer les échappements (appel à echappe_retour)
• ajouter les notes trouvées précédemment aux autres de la page courante

• echappe_html($letexte, $source = "SOURCEPROPRE") : remplace tous les blocs code, poesie, html, cadre, les img, doc, emb et les tags par un marqueur numéroté.
  la liste des blocs retirés est retournée afin de pouvoir remettre ces blocs à la place des marqueurs à la fin des traitements.
  la fonction retourne un tableau de 2 éléments : la liste des blocs retirés + le texte modifié

• interdire_scripts : remplacer tous les <%, <? et <script par des &lt;...

• typo($letexte)
  • appeler echappe_html (c’est pas déjà fait par l’appelant ???)
  • selon la langue courante, on applique typo_fr ou typo_en.
    • typo_en : est_ce que ça se résume pas à un preg_replace("/ *(&nbsp;|~)+ */", "&nbsp;", $letexte) ?
    • typo_fr
      • strtr de quelques caractères (après bidouille sur les charset)
      • preg_replace pour mettre des espaces insécables (autour des :, ; et des Mme, Mr., N° ...)
      • manip pour dédoublonner les espaces insécables
      • manip inverse pour remettre d’aplomb les url !
  • appeler include/filtres.php:corriger_caractères
    • selon le charset courant, définir une table de conversion de caractères (en passant, un switch(charset) case .. $trans=... serait plus clair et plus efficace)
    • faire un strtr dessus
  • faire des jolies apostrophes
  • réinsérer les échappements

Comment faire mieux ?

voila ce que Fil en pense :

pour ce qui est du w3-compliant, je reste persuadé qu’on ne peut le faire bien que si propre() explose d’abord les paragraphes (et les intertitres etc) puis les traite individuellement avant de les recoller. Ca demande de réécrire propre(), mais ça n’est pas forcément monstrueux ; le seul hic risque d’être la vitesse d’exécution.

(NicolasHoizey) Je pense aussi que c’est la meilleure approche pour obtenir un code maintenable, évolutif, et sans doute avec moins d’effets de bord imprévisibles. Est-ce que regarder le code de PEAR ::Text_Wiki ou du WikiRenderer* de Laurent Jouanneau ne pourrait pas nous inspirer ?

(PiiF) j’avais regardé Text_Wiki il y a qqs temps, et je viens de regarder wikirenderer.
Les deux ont à première vue l’avantage d’être configurables, mais c’est en fait vachement orienté wiki (titre marqués par un prefixe, pas de foot notes, mots wiki, ...)
Y’a surement des idées à prendre sur la façon de coder, mais faire un truc aussi paramétrable me semble assez chaud, et finalement pas si souple que ça.
Pour wikirenderer, honnètement, je comprend rien au code ! pour Text_Wiki j’ose même pas essayer : 5936 lignes ! (pour info le formatter de wikini en fait 300)

(NicolasHoizey) Il n’est sans doute pas nécessaire de faire un code configurable, mais sans doute y a t’il des choses à reprendre dans ces projet, notamment au niveau de la découpe d’un texte en une hiérarchie d’éléments unitaires « facilement » interprétables.

C’est quoi "faire mieux"

Il faut faire attention aux effets de bord de toutes modif. Ainsi, éviter d’insérer certains tag p serait plus compliant, mais change le rendu.

(Au début d’un quote, par exemple, si on laisse une ligne vide, on a un espace. Ce bug a été corrigé depuis.)

C’est le gros risque d’effet de bord de toute intervention du type de celles proposées dans CompatibleAFaire.

Méthode (MichaëlParienti) Une suggestion : avant de commencer à recoder la fonction propre, il faudrait écrire une batterie de tests unitaires auxquels devront être soumises les différentes version de la fonction propre. Dans le cas de la fonction propres, les tests unitaires seront définis par par une liste de chaînes, qui seront passées en argument à propre, et dont on testera automatiquement la valeur de retour.
(PiiF) comme signalé dans la page CompatibleAFaire, il y a un article avec plein de trucs pas possibles créé dans ce but. De plus, dans la branche spip_tools du cvs, il y a une page php permettant de comparer l’original avec une version maison

Quelques remarques sur l’existant Il faudrait cogiter sur le sens de certains raccourcis, car avant de recoder ça autrement, y’a quelques points tordus qu’il faudrait éclaircir : RaccourcisQuestions

Les chantiers en cours

• une version est en cours de dev par PiiF, basée sur une nouvelle version de placid .
  la grammaire est là , le parser généré là et un script de test là .
  un article d’exemple est là , l’appeler comme ça : php propreBlocs.php -fichier test.txt ; ça sort un dump de l’arbo de blocs qu’il génère (ja commence à en voir le bout, modulo les paragraphes, qui apparaissent n’importe où)

• une version existe dans SpipModules : ecrire/inc_parser2.php
  ça génère également un dump de blocs mais avec également une phase de transfo en html. Par contre, y’a pas de puces, de tableaux ...

Reste à finaliser un peu et à comparer les résultats, la lisibilité du code, son évolutivité et les perfs.

---