Un paragraphe est généralement forcément multiligne sur le plan visuel.
Ça c’est le résultat du retour à la ligne automatique (premier point). Pas de souci à ce niveau, et toute personne pressée (et ayant d’autres linges à fouetter) est bien contente de ne pas avoir à gérer cela manuellement.
J'ai toujours été étonnée de voir que le comportement du traitement de texte est différent avec des outils comme LinuxFR et SPIP [...]
Pour SPIP tu as du cocher quelque chose dans la configuration (enfin je crois que ça se règle maintenant aussi depuis l’interface d’administration) ou du mettre la bonne option dans le fichier qui va bien (de mémoire mes_options.php) Mais je m’égare, revenons à nos moutons. :)
Dans beaucoup de publications, les paragraphes étaient visuellement bien séparés les uns des autres par un certain espacement : dans la feuille de style que j’utilise ici, c’est le cas. (je ne sais plus si ça vient du thème choisi ou si c’est une surcharge à moi mais c’est du détail sans importance.) Le même principe est appliqué quand on produit des fichiers purement textuels, et donc on laisse au moins une ligne vide entre deux paragraphes : en lisant le fichier je n’ai pas à me demander si ici ou là on passe juste à la ligne ou si c’est un nouveau paragraphe... Les langages de balisage légers (comme Markdown) ont conservé ce principe (que j’utilisais aussi sur machine à écrire...)
Je ne sais pas à partir de quand, mais cet espacement a commencé à être réduit (par souci d’économie ? en tout cas je parle de réduction et non de suppression car il y a des ouvrages où la chose existe bien mais bien discrète — l’espace inter-paragraphes est un peu supérieure à l’interligne) au profit de l’indentation de la première ligne du paragraphe. C’est un peu pénible quand la vue baisse avec l’âge, et avec certains contenus (plutôt denses) et réglages (est-ce la résolution d’écran ou la police utilisée ou un peu de tout ?), sans compter que les traitements automatiques (donc non visuels) diffèrent selon qu’il s’agissent de paragraphe ou pas : raison pour laquelle je préfère que les traitements de texte marquent ces sauts/changements... (¶§⁋⸿❡⏎↵↩)
Les traitements de textes n’utilisent pas un fichier purement texte et utilisent d’autres moyens pour arriver aux résultats attendus (typiquement pas besoin d’indiquer le paragraphe par de vrais sauts de lignes, mais en interne par des codes qui indiquent qu’il faut se décaler d’une certaine distance verticalement par rapport à la ligne précédente). De ce fait, ils ont décidés à un moment (comme on dit, références souhaitées, mais je fouillerai plus tard ; je sais juste que ça n’a pas toujours été le cas) que comme ce sont les paragraphes que l’on fait le plus souvent bah il fallait le faire d’un appui de touche. (tiens, il me semble avoir déjà vu un éditeur Markdown de type « visuel » qui fait quelque chose du genre, preuve que l’interface n’a aucun lien avec le format sous-jacent car en ouvrant le fichier avec un éditeur de texte je voyais bien que ça m’avait inséré une ligne vide.)
Ce choix a l’avantage de ne pas permettre facilement des sauts de ligne forcés. Mais comme tu sais, les gens n’étant pas formés à l’utilisation des traitements de texte se sont retrouvés à quand même à mélanger les sauts de lignes et les paragraphes et ce fut une vraie boucherie...
Il se trouve en effet que l’on a de temps en temps légitimement besoin de faire des sauts de ligne forcés. Avec ton éditeur de texte, tu fais juste un retour charriot, c’est logique et cohérent. :D Les traitements de texte ont réintroduit le truc par des combinaisons de type Majuscule&Retour ou Contrôle&Retour ou que sais-je, que peu de leurs usagers connaissent. :(
Avec les langages de balisage, il y a deux écoles. Une qui fonctionne comme avec le texte non balisé dans l’éditeur de texte, même s’il n’y en a pas qui me vienne à l’esprit tout de suite. Ah si, le Markdown de Linuxfr. ;) L’autre école stipule que le simple retour de ligne et les espaces ne sont pas significatifs, et qu’il faut convenir d’un moyen de baliser explicitement le saut de ligne forcé. C’est le cas bien connu de : HTML (<br>), XHTML (<br/>), LaTeX (\\), et Markdown original () ...c’est le choix le plus étrange que j’ai vu, mais pour sa défense on peut mettre du HTML... C’est ce que je fais, parce que comme d’autres ici je ne suis pas fan des caractères invisibles bien que mon éditeur soit configuré pour me les indiquer. C’est que je n’ai pas toujours le loisir de pouvoir composer avec le confort de mon éditeur. CommonMark non plus n’est pas fan mais a gardé pour la compatibilité et rajouté un marquage plus visible (\) En fait il s’agit là du saut de ligne forcé dans le flux standard comme celui-ci, et les langages de balisage distinguent souvent un certain nombre de cas légitimes où le saut de ligne est automatiquement actif sans devoir le marquer/baliser : dans SPIP par exemple il y a les balises code et poesie qui font cela.
Bien, avant que j’oublie pourquoi j’avais commencé à écrire, il n’y a pas de différence de comportement : des deux (ou plus côtés) on encode le fait de faire un saut de ligne forcé et le fait de faire un nouveau paragraphe. Ce sont plutôt les interfaces qui sont différentes pour des raisons qui sont propres à chaque univers. L’interface des traitements de texte veut que l’on produise des paragraphes et qu’on ne se préoccupe pas des retours à la ligne. Un langage de balisage n’a pas d’interface, de base (il est toujours possible d’en trouver du plus ou moins wysiwyg) ; et la plupart des balisages légers veulent que le texte puisse se lire directement comme s’il n’est pas formaté. Du coup, ça fait sens d’avoir un retour de ligne qui soit toujours physique (solution LinuxFr) ou un marquage discret (comme pour les gens qui affichent les marques de sauts invisibles par le traitement de texte), et une vraie nette séparation entre les paragraphes. Des publics/populations différent/e/s.
Voici maintenant un multilignes manuellement forgé et non une suite de paragraphes... Il serait bien de le saisir dans LibreOffice, dans un nouveau document vierge, puis de produire le Markdown et coller le résultat en réponse :
Première gelée
Mes pas crissent sur l’herbe
Monde cristallin
"It is seldom that liberty of any kind is lost all at once." ― David Hume
[^] # Re: Debian
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse à la dépêche LibreOffice 26.2 : Markdown, accessibilité et plein d’autres nouveautés et améliorations. Évalué à 2.
Ça c’est le résultat du retour à la ligne automatique (premier point). Pas de souci à ce niveau, et toute personne pressée (et ayant d’autres linges à fouetter) est bien contente de ne pas avoir à gérer cela manuellement.
Pour SPIP tu as du cocher quelque chose dans la configuration (enfin je crois que ça se règle maintenant aussi depuis l’interface d’administration) ou du mettre la bonne option dans le fichier qui va bien (de mémoire
mes_options.php) Mais je m’égare, revenons à nos moutons. :)Dans beaucoup de publications, les paragraphes étaient visuellement bien séparés les uns des autres par un certain espacement : dans la feuille de style que j’utilise ici, c’est le cas. (je ne sais plus si ça vient du thème choisi ou si c’est une surcharge à moi mais c’est du détail sans importance.) Le même principe est appliqué quand on produit des fichiers purement textuels, et donc on laisse au moins une ligne vide entre deux paragraphes : en lisant le fichier je n’ai pas à me demander si ici ou là on passe juste à la ligne ou si c’est un nouveau paragraphe... Les langages de balisage légers (comme Markdown) ont conservé ce principe (que j’utilisais aussi sur machine à écrire...)
Je ne sais pas à partir de quand, mais cet espacement a commencé à être réduit (par souci d’économie ? en tout cas je parle de réduction et non de suppression car il y a des ouvrages où la chose existe bien mais bien discrète — l’espace inter-paragraphes est un peu supérieure à l’interligne) au profit de l’indentation de la première ligne du paragraphe. C’est un peu pénible quand la vue baisse avec l’âge, et avec certains contenus (plutôt denses) et réglages (est-ce la résolution d’écran ou la police utilisée ou un peu de tout ?), sans compter que les traitements automatiques (donc non visuels) diffèrent selon qu’il s’agissent de paragraphe ou pas : raison pour laquelle je préfère que les traitements de texte marquent ces sauts/changements... (¶§⁋⸿❡⏎↵↩)
Les traitements de textes n’utilisent pas un fichier purement texte et utilisent d’autres moyens pour arriver aux résultats attendus (typiquement pas besoin d’indiquer le paragraphe par de vrais sauts de lignes, mais en interne par des codes qui indiquent qu’il faut se décaler d’une certaine distance verticalement par rapport à la ligne précédente). De ce fait, ils ont décidés à un moment (comme on dit, références souhaitées, mais je fouillerai plus tard ; je sais juste que ça n’a pas toujours été le cas) que comme ce sont les paragraphes que l’on fait le plus souvent bah il fallait le faire d’un appui de touche. (tiens, il me semble avoir déjà vu un éditeur Markdown de type « visuel » qui fait quelque chose du genre, preuve que l’interface n’a aucun lien avec le format sous-jacent car en ouvrant le fichier avec un éditeur de texte je voyais bien que ça m’avait inséré une ligne vide.)
Ce choix a l’avantage de ne pas permettre facilement des sauts de ligne forcés. Mais comme tu sais, les gens n’étant pas formés à l’utilisation des traitements de texte se sont retrouvés à quand même à mélanger les sauts de lignes et les paragraphes et ce fut une vraie boucherie...
Il se trouve en effet que l’on a de temps en temps légitimement besoin de faire des sauts de ligne forcés. Avec ton éditeur de texte, tu fais juste un retour charriot, c’est logique et cohérent. :D Les traitements de texte ont réintroduit le truc par des combinaisons de type Majuscule&Retour ou Contrôle&Retour ou que sais-je, que peu de leurs usagers connaissent. :(
Avec les langages de balisage, il y a deux écoles. Une qui fonctionne comme avec le texte non balisé dans l’éditeur de texte, même s’il n’y en a pas qui me vienne à l’esprit tout de suite. Ah si, le Markdown de Linuxfr. ;) L’autre école stipule que le simple retour de ligne et les espaces ne sont pas significatifs, et qu’il faut convenir d’un moyen de baliser explicitement le saut de ligne forcé. C’est le cas bien connu de : HTML (
<br>), XHTML (<br/>), LaTeX (\\), et Markdown original () ...c’est le choix le plus étrange que j’ai vu, mais pour sa défense on peut mettre du HTML... C’est ce que je fais, parce que comme d’autres ici je ne suis pas fan des caractères invisibles bien que mon éditeur soit configuré pour me les indiquer. C’est que je n’ai pas toujours le loisir de pouvoir composer avec le confort de mon éditeur. CommonMark non plus n’est pas fan mais a gardé pour la compatibilité et rajouté un marquage plus visible (\) En fait il s’agit là du saut de ligne forcé dans le flux standard comme celui-ci, et les langages de balisage distinguent souvent un certain nombre de cas légitimes où le saut de ligne est automatiquement actif sans devoir le marquer/baliser : dans SPIP par exemple il y a les balisescodeetpoesiequi font cela.Bien, avant que j’oublie pourquoi j’avais commencé à écrire, il n’y a pas de différence de comportement : des deux (ou plus côtés) on encode le fait de faire un saut de ligne forcé et le fait de faire un nouveau paragraphe. Ce sont plutôt les interfaces qui sont différentes pour des raisons qui sont propres à chaque univers. L’interface des traitements de texte veut que l’on produise des paragraphes et qu’on ne se préoccupe pas des retours à la ligne. Un langage de balisage n’a pas d’interface, de base (il est toujours possible d’en trouver du plus ou moins wysiwyg) ; et la plupart des balisages légers veulent que le texte puisse se lire directement comme s’il n’est pas formaté. Du coup, ça fait sens d’avoir un retour de ligne qui soit toujours physique (solution LinuxFr) ou un marquage discret (comme pour les gens qui affichent les marques de sauts invisibles par le traitement de texte), et une vraie nette séparation entre les paragraphes. Des publics/populations différent/e/s.
Voici maintenant un multilignes manuellement forgé et non une suite de paragraphes... Il serait bien de le saisir dans LibreOffice, dans un nouveau document vierge, puis de produire le Markdown et coller le résultat en réponse :
Première gelée
Mes pas crissent sur l’herbe
Monde cristallin
"It is seldom that liberty of any kind is lost all at once." ― David Hume