retours chariots

Général
21

non en SPIP 3, un simple retour produit un retour ligne <br>, pas un
changement de paragraphe <p>.

Du coup, je profite du fil pour poser une question : sur un site commencé en 1.9xxx et qui a évolué régulièrement jusqu'à la dernière version stable de la branche 2.1, un bon paquet d'articles (plus de 2000 !) contiennent des retours lignes "sans conséquence" (= dans ces versions, un retour ligne ne produisaient rien).

C'est carrément stressant comme situation, car il faudra bien un jour passer en version 3 et là tous ces "faux" retours à la ligne qui n'en étaient pas vont se retrouver transformés en br

Comment feriez-vous (requête SQL ?)pour mettre les textes d'aplomb et transformer le contenu de la base de données pour que les retours chariot simples (qui ne sont pas pris en compte à l'affichage) soient tous simplement supprimés et remplacés par un "espace" tout en ne touchant pas au double saut de paragraphes destinés à créer des paragraphes ?

Merci d'avance de vos lumières

22

Le 01/12/2014 10:15, Christian Marget a écrit :

Bonjour,

Le 01/12/2014 08:09, Ysabeau a écrit :

En traitement de texte : un appui sur la touche entrée créé un *vrai*
paragraphe (<p>) et pas un retour de ligne forcée (<br>).

Tu confonds "traitement de texte" et "éditeur de texte". C'est une
différence fondamentale :

Oh que non ! J'ai même commis un article sur les différences entre les deux en 2012.

- un traitement de texte effectue une mise en forme selon ses codes
propres, pas forcément compatibles avec les autres TdT
- un éditeur de texte se contente d'aligner des caractères sans codes
cachés. Tout le monde peut donc lire et utiliser les textes produits
mais s'il y a des codes de mise en forme, ils doivent être explicitement
visibles dans le texte.

Un traitement de texte (notammment wysiwyg) utilise des codes "masqués"
(par exemple Entrée/Ctrl-entrée) pour distinguer saut de ligne et saut
de paragraphe. Idem pour les enrichissements divers, gras, italiques, etc.

Et hop :frowning: je passe mon temps à expliquer ça à mes stagiaires pour leur dire pourquoi il faut utiliser les styles pour mettre en forme leur texte dans un traitement de texte et pourquoi c'est génial parce que c'est la base de l'écriture numérique et que du coup ça permet, par exemple, à un CMS, de reconnaître les textes bien mis en forme donc bien balisés (je ne parle pas des saloperies de bidouillages que tu cites...).

L'éditeur de SPIP est un éditeur de texte, il ne peut utiliser que des
caractères visibles. Les enrichissements apparaissent sous forme de
codes comme {italiques}. Dans ce contexte, un saut de ligne = un saut de
ligne. Un double saut de ligne symbolise l'espacement vertical entre
deux paragraphes. C'est certes une convention mais elle facilite
énormément la (re-)lecture.

Je suis vraiment désolée, mais la relecture avec toutes les accolades (en plus je ne sais jamais combien il en faut pour un titre ou du gras), etc. est rendue plus ardue. Ce débat a déjà été donné dix mille fois ici.
Heureusement qu'il y a odt2spip...

D'ailleurs dans tes mails, tu sautes bien 2 lignes pour marquer les
paragraphes...

Non ! Enfin si, uniquement pour que ça soit plus aéré à l’œil, ce qui n'est pas une chose à faire.

--
Ysabeau

23

Le 1 décembre 2014 10:29, Ysabeau <id@dutailly.net> a écrit :

Un traitement de texte (notammment wysiwyg) utilise des codes "masqués"
(par exemple Entrée/Ctrl-entrée) pour distinguer saut de ligne et saut
de paragraphe. Idem pour les enrichissements divers, gras, italiques, etc.

[...]
(je ne parle pas
des saloperies de bidouillages que tu cites...).

Je crois bien au contraire que dans les principaux traitements de
texte WYSIWYG l'utilisation du Ctrl-Entrée est une *bonne pratique*
pour certains usages (adresses par exemple).

--
Beurt

24

Le 01.12.14 10:28, Manu a écrit :

non en SPIP 3, un simple retour produit un retour ligne <br>, pas un
changement de paragraphe <p>.

Du coup, je profite du fil pour poser une question : sur un site
commencé en 1.9xxx et qui a évolué régulièrement jusqu'à la dernière
version stable de la branche 2.1, un bon paquet d'articles (plus de 2000
!) contiennent des retours lignes "sans conséquence" (= dans ces
versions, un retour ligne ne produisaient rien).

C'est carrément stressant comme situation, car il faudra bien un jour
passer en version 3 et là tous ces "faux" retours à la ligne qui n'en
étaient pas vont se retrouver transformés en br

Comment feriez

-vous (requête SQL ?)pour mettre les textes d'aplomb et

transformer le contenu de la base de données pour que les retours
chariot simples (qui ne sont pas pris en compte à l'affichage) soient
tous simplement supprimés et remplacés par un "espace" tout en ne
touchant pas au double saut de paragraphes destinés à créer des
paragraphes ?

Merci d'avance de vos lumières

tu configure SPIP pour garder le comportement historique

--
Maïeul

25

Bonjour,

Le 1 décembre 2014 10:28, Manu <manu@mine-de-rien.fr> a écrit :

Du coup, je profite du fil pour poser une question : sur un site commencé
en 1.9xxx et qui a évolué régulièrement jusqu'à la dernière version stable
de la branche 2.1, un bon paquet d'articles (plus de 2000 !) contiennent
des retours lignes "sans conséquence" (= dans ces versions, un retour ligne
ne produisaient rien).

C'est carrément stressant comme situation, car il faudra bien un jour
passer en version 3 et là tous ces "faux" retours à la ligne qui n'en
étaient pas vont se retrouver transformés en br

Comment feriez-vous (requête SQL ?)pour mettre les textes d'aplomb et
transformer le contenu de la base de données pour que les retours chariot
simples (qui ne sont pas pris en compte à l'affichage) soient tous
simplement supprimés et remplacés par un "espace" tout en ne touchant pas
au double saut de paragraphes destinés à créer des paragraphes ?

Merci d'avance de vos lumières

Méthode simple : conserver l'ancien comportement, define('_AUTOBR', '');
dans mes_options.php

Méthode correction automatique de la base :
Connexion · GitLab (backup
et vérification à prévoir)

26

Méthode simple : conserver l'ancien comportement, define('_AUTOBR', '');
dans mes_options.php

Oui, je connaissais cette option "rustine" mais qui m' toujours ennuyé car, dans le fond, ce que je cherche à faire c'est à remettre les textes "au carré"

Méthode correction automatique de la base :
Connexion · GitLab
(backup et vérification à prévoir)

Cool, ça je connaissais pas...
Je vais essayer sur une version locale du site

Merci (beaucoup)