Intégrer la typographie dans le traitement du markdown

En tant que correcteur de divers articles et tutos, je suis régulièrement amené à corriger, en de très nombreuses occurrences, des petits détails de typographie française difficiles à intégrer sans un clavier adapté. Or, une partie de ces modifications peuvent se faire de manière automatique (c'est juste chiant quand il faut le faire extrait par extrait). Ma suggestion serait donc d'intégrer ces corrections automatiques au processus de traitement du markdown.

Les corrections à effectuer seraient les suivantes.

• Remplacer les guillemets droits simples ' par des apostrophes typographiques ’.
• Remplacer les guillemets droits doubles " par des guillemets français, soit ouvrant et suivi d'une espace insécable (&#xA0 en HTML) «  si le guillemet droit est précédé d'une espace ordinaire, soit fermant et précédé d'une espace insécable  » si le guillemet droit est suivi d'une espace ordinaire. Ainsi, essai "test" voilà deviendrait essai « test » voilà.
• Remplacer le double-point : précédé d'une espace ordinaire par un double-point précédé d'une espace insécable.
• Remplacer le point-virgule ;, le point d'interrogation ? et le point d'exclamation ! précédés d'une espace ordinaire par les mêmes précédés d'une espace fine insécable (&#x202F en HTML). À noter que l'espace fine insécable est apparue avec Unicode 3 et que si ça pose des problèmes de compatibilité, on peut utiliser une espace insécable à la place.
• Remplacer une série de trois points ... par des points de suspension …. (NOTA : ça a l'air d'être déjà le cas quand on les met entre des balises ||.)
• Éventuellement, remplacer un double tiret entouré d'espaces ordinaires -- par un tiret cadratin et ses espaces — . (Là aussi, les balises || semblent effectuer un traitement sur le double tiret.)
• À la rigueur, remplacer un tiret entre deux nombres par un tiret insécable ‑ : 1202-1213 deviendrait 1202‑1213.

L'intérêt de les intégrer au zMarkdown, c'est bien évidemment que l'auteur (ou ses correcteurs) n'ait plus à le faire à la main, ce qui peut s'avérer fastidieux sous Windows. Mais également que ces modifications n'ont pas lieu d'être entre des balises de code ou entre des balises ||, et qu'en dehors même de ces balises, il serait possible de les interdire grâce à un backslash : \' ne serait pas transformé en apostrophe typographique, par exemple. Toutes choses que le zMarkdown gère déjà.

Cela ne réglera évidemment pas toutes les fautes de typographie, mais cela permettra d'améliorer considérablement le rendu général des contenus du site.

Très bonne idée, mais il faudrait pouvoir désactiver une correction. Par exemple, il serait laborieux d'échapper tous les guillemets si je les veux tous anglais.

Moui… Les guillemets droits doubles ne sont pas corrects non plus en typographie anglaise. Les guillemets anglais corrects sont “ et ”.

J'ai oublié de le préciser, mais j'ai vérifié que cela n'interfère pas avec la typographie propre des autres langues : les principales langues d'Europe utilisant l'alphabet latin ont leurs propres formes de guillemets (qu'il faut donc entrer à la main quoi qu'il arrive), ne mettent pas d'espace avant les ponctuations doubles (donc ne seront pas touchées par la correction) et utilisent le point de suspension et l'apostrophe typographique exactement comme nous. Le seul point que je n'ai pas vérifié, c'est concernant le tiret insécable.

En fait c'est le cas tout le temps, pas que dans ces balises : … bla – blabla — truc

Il faut bien penser à tous les effets de bord possibles avant d'implémenter un truc. En particulier, on a pas mal de code, il ne faut surtout pas que ça l'impacte.

Je pense aussi qu'au-delà d'automatiser en masse, on pourrait sensibiliser les auteurs à ces problématiques, par exemple en leur indiquant divers outils pour les aider à appliquer une bonne typographie un peu partout – et pas seulement sur ce site.

Il ne faut pas non plus oublier que les règles que tu donnes sont celles du français de France. Le français d'autres pays peut suivre d'autres conventions tout en restant parfaitement valable.

Aujourd'hui on a :

• -- donne – (tiret demi-cadratin)
• --- donne — (tiret cadratin)
• ... donne … (je ne savais pas qu'on le gérait)

PS : les guillemets droits, curieusement présents sur à peu près tous les claviers du monde, ne sont corrects dans aucune langue à ma connaissance. Mais ça permettait de gagner une touche en utilisant le même guillemet pour ouvrir et fermer…

En particulier, on a pas mal de code, il ne faut surtout pas que ça l'impacte.

Ça tombe bien, comme je l'explique dans mon premier message, le zMarkdown est déjà habitué à ne pas agir sur le contenu des blocs / spans de code, donc le problème ne se posera pas.

Il ne faut pas non plus oublier que les règles que tu donnes sont celles du français de France. Le français d'autres pays peut suivre d'autres conventions tout en restant parfaitement valable.

Là aussi, je me suis renseigné, et la seule différence notable, c'est que le français de Suisse ne met généralement pas d'espace entre les guillemets et leur contenu. Cela étant, cette spécificité n'est pas nécessairement suffisante pour justifier de ne pas adopter la correction automatique : Wikipédia, par exemple, a pris le parti d'imposer la formule la plus courante à l'échelle de la Francophonie.

Je suis totalement favorable a cela. Il s'agit de grep / replace. Au pire on met ca avant l'envoie en validation -> traitement automatique -> visualisation du diff par l'auteur -> acceptation / corrections specifiques -> envoie definitif en validation.

Notons aussi qu'il est conseille d'utiliser une espace fine pour les guillemets francais. Pour etre precis, un quart de cadratin. Par contre j'ai lu qu'il n'etait pas non-secable en unicode d'ou l'utilisation d'une espace non-secable mais non fine.

PS : les guillemets droits, curieusement présents sur à peu près tous les claviers du monde, ne sont corrects dans aucune langue à ma connaissance. Mais ça permettait de gagner une touche en utilisant le même guillemet pour ouvrir et fermer…

Ils sont autorises en polonais. Source : http://sjp.pwn.pl/zasady/;629866

J'approuve l'idée. On peut imaginer une case à cocher en-dessous de l'éditeur :

Voulez-vous appliquer les corrections automatiques de typographie française ?

Après, si la case est cochée, on pourra effectuer des corrections assez poussées : même s'il n'y a pas d'espace avant un ! ou un ?, on peut le rajouter (insécable). Par contre, il faudra bien vérifier que les corrections ne s’effectuent que dans des zones précises, pas dans les balises de code par exemple. De plus, il n'est pas évident de gérer les guillemets simples : comment savoir s'il s'agit d'un guillemet ou d'une apostrophe ?

PS: Peut-être qu'il est possible de s'inspirer de la manière dont SPIP gère cela, il est plutôt réputé pour bien s'occuper des corrections typos.

NB: le code actuel entre zds et le parseur markdown n'est pas spécialement fait pour moduler le parsing en fonction d'une case a cocher quelque part.

Conseillé par qui ? À part en Suisse, où ils ont effectivement une règle différente ?

En France, le Lexique typo de l'Imprimerie nationale recommande une espace insécable ordinaire. N'étant pas chez moi, je n'ai pas le Nouveau code typo sous la main, si quelqu'un peut vérifier ce qu'ils en disent…

Au Canada, Le guide du rédacteur du Bureau de la traduction utilise des espaces insécables ordinaires, et l'Office québécois de la langue française ne recommande l'usage des espaces fines insécables que pour ?, ! et ; donc pas les guillemets.

J'ai plus de mal à trouver des infos pour la Belgique. Wikipédia met la question de l'espacement des guillemets dans les différences entre typo suisse et typo française, mais pas dans les différences entre typo belge et typo française. Ce site affirme bien que la Belgique suit la même règle qu'en France. Et cet ouvrage ancien (1915) dit qu'il y a des demi-cadratins d'espace à l'intérieur des guillemets en Belgique.

Et on ne peux pas imaginer sinon un booléen dans le fichier manifest.json de l'article ou du tuto concerné qui indique si oui ou non il faut effectuer les corrections ?

Lexique des règles typo­gra­phiques en usage à l’Im­pri­me­rie natio­nale. En fait c'est egalement la regle pour ;!?: (espace fine insecable avant). Pour etre plus juste, ce serait un quart de cadratin, mais en typographie numerique, en Unicode, il n'est pas insecable, et du coup l'espace fine insecable numerique est plus proche du cinquieme de cadratin.

Quelques exemples sur le web:

• http://typographisme.net/post/Les-espaces-typographiques-et-le-web
• http://www.graphicvertigo.com/elephant/les-regles-typographiques-de-la-ponctuation-francaise-episode-01/
• http://francois.huet.free.fr/typographie/
• http://www.tnformation.com/pdf/guillemets.pdf

Note dans le dernier document le 'fine si possible' qui provient du probleme que j'ennonce plus haut. J'ai aussi trouve des notices d'editeurs qui ennonce egalement ce fait et que Word par exemple ne permet pas de faire d'espace fine et que ceux-ci seront ajoutes par l'imprimeur.

Je plussoie Matouche, parce que même s'il y a clairement une valeur ajoutée en améliorant la typographie, certains rédacteurs risquent de ne pas apprécier ne pas pouvoir contrôler ce paramètre.

Du moment que c'est du ouvrant-fermant, ça devient plus délicat à corriger, surtout si le rédacteur a oublié d'en mettre quelque part.

On peut imaginer aussi des cas plus tordus dont le traitement n'est pas forcément évident (!?, !!!, ??? etc).

Ça revient au même. C'est le passage d'une infos du site au parseur. D'où qu'elle viennent, ce n'est actuellement pas spécialement prévu. Après c'est pas impossible, ça complique juste les choses. Plus les conditions seront simple, mieux ce sera.

D'ou l'idee d'avoir un ecran intermediaire avec un diff pour l'auteur, pour qu'il puisse faire les modifications lui meme en cas de pepin (ou annuler si malheureusement il y a trop de choses a retoucher, ce qui ne devrait pas arriver si 1. l'auteur n'a pas une typographie moisie de base, 2. le systeme est relativement bien concu).

D'ou l'idee d'avoir un ecran intermediaire avec un diff pour l'auteur, pour qu'il puisse faire les modifications lui meme en cas de pepin (ou annuler si malheureusement il y a trop de choses a retoucher, ce qui ne devrait pas arriver si 1. l'auteur n'a pas une typographie moisie de base, 2. le systeme est relativement bien concu).

Ça, ça va vite devenir le bordel en fait. A chaque édition tu devras tout te retaper les correction et en plus ça pourrait être dépendant du type de sortie. On ne peut pas le faire avec un pré-processeur qui modifie le markdown car on aurait bien d'autres problème, principalement qu'il faut être capable de détecté que l'on est pas dans des balises codes par exemple. La chaine actuel est pas du tout faite pour ça. Quitte a choisir il vaut mieux que ça se résume à un boolean associé a chaque extrait pour savoir si la sortie doit tenter de faire les corrections elle meme. J'ai peur que ça rende l'édition un peu compliqué mais c'est déjà plus simple que de vouloir faire une correction des sources avant ou un diff.

Dans l'idee, la correction typogrpahique n'intervient vraiment qu'en toute derniere etape. Auquel cas, le diff permet simplement de controler ce que le traitement automatique a produit, et de corriger facilement grace au diff des petites choses comme des cas limites ou l'utilisation volontaire de guillements etrangers.

Non, vraiment pas ! Je cite.

Et la page suivante précise bien « espace mots insécable » avant les deux-points, avant le guillemet fermant et après le guillemet ouvrant. D'ailleurs, ce tableau de la page 149 est repris dans tes deux premiers liens, le troisième dit la même chose avec des mots et le quatrième est une repompe totale de Wikipédia, qui dit toujours la même chose.

L'idée, c'est que les guillemets droits sont toujours collés à ce qu'ils entourent, comme c'est d'usage en typographie anglaise. Du coup, un guillemet droit précédé d'une espace (ou premier caractère du paragraphe) est logiquement un guillemet ouvrant et un guillemet droit suivi d'une espace (ou d'un signe de ponctuation non espacé) est un guillemet fermant.

Par exemple, prends la phrase suivante. Marc ajouta : "Je lui ai dit "T'es vraiment aussi moche que ta femme" et curieusement, il l'a mal pris", avant de partir d'un grand rire. Il n'y a aucune difficulté à savoir lesquels sont ouvrants ou fermants, même si par une faute de frappe, l'un vient à manquer.

Je vois pas le souci. C'est le premier signe de ponctuation qui détermine quelle espace doit être mise avant. Un str_replace de " ?" vers " ?" et de " !" vers " !" règle aussi tes « cas tordus ».

En même temps les conventions typographiques sont des conventions et non des règles absolues. Vous êtes en train de vous prendre la tête pour des détails qui n'ont aucun intérêt. Le but des tutos sur ZdS, c'est d'avoir une typographie suffisamment propre pour être facilement lisible et si possible à peu près homogène.

Si vous voulez vraiment faire avancer le sujet et sauver des drosophiles, réfléchir aux cas particuliers me semble plus utile (on sait que le cas du code est géré aujourd'hui ; mais qu'en est-il des balises "touche", des autres balises, du code inline, de la ponctuation multiple ?!)

Bon bah j'ai definitivement fume la moquette. Je cite comme source des trucs qui disent le contraire de ce que j'affirme. :}

Pour ce qui est des touches et du code (inline comme bloc), il ne faut pas y toucher. Il faut aussi garder intactes toutes les URLs, qu'elles soient ou non encadrées par des balises <a>. Évidemment on ne doit pas toucher non plus aux href et src, mais pourquoi pas pour le texte alternatif…

Pour ce qui est de la solution proposée par Dominus Carnufex concernant les guillemets et les points d'exclamation et d'interrogation, j'émets un doute. Il est fréquent d'oublier l'espace, même sécable. On doit donc aussi imaginer le cas suivant, qui ne me semble pas si tiré par les cheveux que ça. Marc ajouta:"Que tu es moche!"