[spip-dev] Retours à la ligne simples

Hello,

Je souhaite que dans le champ "PS" l'utilisateur puisse saisir un texte
comprenant des retours à la ligne simples, qui se transforment tout
naturellement en retour à la ligne simples côté site public, tout ça sans
passer de ligne ou utiliser de "_" lors de la saisie.

Dans "articles.php3", j'affiche le contenu du "PS" en remplaçant les "\n" en
"<br>" et ça marche.
Dans mon squelette sur le site public, ce genre de manoeuvre (après
récupération dans une variable php) ne marche pas, ce qui me laisse penser
que ce n'est plus "\n" ou "\r\n" que je dois rechercher.

Le contenu de "PS" est-il filtré lors du calcul du squelette avant son
affectation à la balise "#PS" ?
J'ai raté quelque-chose ?

Gilles

Oui, ca existe déjà dans la version CVS, voir les archives de la liste. Post
de Fil, si je me souviens bien.

"FEVRIER" <gilles_fevrier@hotmail.com> a écrit dans le message de news:
c24q3p$hts$1@sea.gmane.org...

Hello,

Je souhaite que dans le champ "PS" l'utilisateur puisse saisir un texte
comprenant des retours à la ligne simples, qui se transforment tout
naturellement en retour à la ligne simples côté site public, tout ça sans
passer de ligne ou utiliser de "_" lors de la saisie.

Dans "articles.php3", j'affiche le contenu du "PS" en remplaçant les "\n"

en

Salut,

"Saturne" <benjamin_nesme@hotmail.com> a écrit dans le message de
news:c24rdo$lg5$1@sea.gmane.org...

Oui, ca existe déjà dans la version CVS, voir les archives de la liste.

Post

de Fil, si je me souviens bien.

Je pense avoir trouvé le message en question (daté du 23/02) dans lequel Fil
explique qu'il a créé un nouveau filtre "post_autobr()".

J'ai récupéré les modifs effectuées dans "inc_texte.php3" et
"inc_filtres.php3".

Par contre, je n'arrive pas à utiliser ce filtre dans mon squelette.
Par défaut, il a le comportement classique (saut de ligne si elle commence
par "_"). C'est donc normal qu'il ne se passe rien (je ne souhaite pas que
mes utilisateurs aient à saisir un "_" à chaque fois).
J'essaie de passer un paramètre au filtre : [(#PS|post_autobr{"\n"})], mais
je n'ai guère plus de succès.

Quelqu'un a déjà utilisé ce filtre ? Peut-être que je ne recherche pas la
bonne chaîne de caractères...

A+

Gilles

Je pense avoir trouvé le message en question (daté du 23/02) dans lequel Fil
explique qu'il a créé un nouveau filtre "post_autobr()".

Oui, mais ça n'est plus vraiment d'actualité, car trop lourd du point de vue
de l'interface

Par contre, je n'arrive pas à utiliser ce filtre dans mon squelette.

Ce n'est *pas* fait pour être utilisé dans le squelette ; c'est fait pour
filtrer les données au moment où elles sont envoyées par le rédacteur. La
question de l'interface est donc primordiale.

-- Fil

comment ça trop lourd?
Qqun peut il me donner une raison pour laquelle dans spip et dans presque
tous les wiki il faut taper un code spéciale pour revenir à la ligne,
pourquoi le simple retour à la ligne lors de la saisie ne le fait il pas
tout seul?
Est ce purement technique ou pour des raisons editoriales?

"Fil" <fil@rezo.net> a écrit dans le message de
news:20040304123603.GB17259@rezo.net...

Je pense avoir trouvé le message en question (daté du 23/02) dans lequel

Fil

explique qu'il a créé un nouveau filtre "post_autobr()".

Oui, mais ça n'est plus vraiment d'actualité, car trop lourd du point de

vue de l'interface

Par contre, je n'arrive pas à utiliser ce filtre dans mon squelette.

Ce n'est *pas* fait pour être utilisé dans le squelette ; c'est fait pour

filtrer les données au moment où elles

sont envoyées par le rédacteur. La question de l'interface est donc

primordiale.

Ouin, pourquoi tant de haine ??? :slight_smile:
Bon, y'a pas une solution pour qu'un saut de ligne dans la saisie soit un
saut de ligne à l'affichage ?
Je ne demande pas une intégration dans SPIP, c'est pour une application
basée sur SPIP. Le problème, c'est que je ne trouve pas l'endroit où il est
dit que "_" signifie retour à la ligne, que je pourrais modifier...

Gilles (pour info, je suis basé sur une 1.6)

Des raisons, y'en a des brouettes.

1. Le retour à la ligne (retour-chariot) n'existe quasiment pas en typographie. Quand on change de paragraphe, on change de paragraphe; libre au webmestre ensuite de définir le comportement (feuille de style "p.spip") de ce paragraphe: soit Web classique (espace vertical entre les paragraphes), soit façon littérature (pas d'espacement vertical, mais indentation de la première ligne).

Sur le Web, l'utilisation de <br> (retour à la ligne simple) est dans 99% des cas une grosse erreur de typo. Elle consiste à vouloir simuler la présentation "littéraire" des paragraphes (pas d'espacement vertical), sans bénéficier d'aucun de ses avantages; et créer deux types de "sauts de paragraphe": certains peu marqués (retour à la ligne), d'autres très marqués (saut d'une ligne). C'est un très mauvais choix typographique. Signalons de plus que le <br>, qui ne propose ni espacement vertical, ni indentation de la première ligne, ne permet pas d'identifier à coup sûr un changement de ligne, et détruit la lisibilité générale du texte (pas de repères de déplacement vertical de la lecture).

Dans SPIP, pour promouvoir une certaine "qualité" typographique, la possibilité de retour à la ligne, presque toujours utilisée mal-t'à-propos, n'est pas mise en avant.

2. Utilisé comme changement "discret" de paragraphe, c'est de plus une horreur à mettre en page par la suite: pas d'identification d'une "première ligne" du paragraphe, donc pas d'indentation, etc. On a tout à gagner à travailler avec des <p></p> propres.

3. Les très rares cas où le retour à la ligne sont justifiés d'un point de vue typographique sont:
      - la publication de code informatique; dans ce cas, SPIP propose le raccourci <cadre></cadre>, qui offre par ailleurs d'autres avantages d'utilisation (copier-coller très facile du code, respect des indentations, pas d'intrusion typographique dans le code),
      - la poésie, les chansons... nous venons d'introduire le nouveau raccourci <poesie></poesie> pour cela.

4. A l'inverse, la possibilité, même "locale" d'insérer des retours-chariot, à la discrétion des rédacteurs, nuit à l'homogénéité du site: les "paragraphes" seront alors différents selon les articles (<p> dans certains articles, <br> dans d'autres). Donc soit on obtient des sites crados du point de vue de l'homogénéité typographique, soit les administrateurs passeront leur temps à faire le ménage.

5. Les textes publiés sur l'internet via ces interfaces sont souvent de sources hétérogènes, provenant de copier-coller plus ou moins sauvages (copie d'un mail, copie d'un fichier PDF, etc.). Du coup, la présence ou non de retour-chariot bizarroïdes est souvent la règle. On travaille alors beaucoup plus rapidement quand on ignore les retour-chariot en fin de ligne (on se contente, éventuellement, d'ajouter quelques sauts de paragraphe), plutôt que de devoir supprimer tous les retour-chariot inutiles du texte (à la fin de chaque ligne).

6. Pour l'heure, la plupart des systèmes de proposent pas d'édition Wysiwyg: du coup on se permet de "profiter" de l'avantage de l'édition non wysiwyg, qui est de manipuler facilement des textes non ou mal mis à forme, le traitement typographique automatique corrigeant ensuite certaines approximations (par exemple: dans SPIP si on saute 2 lignes entre deux paragraphes, cela reste bien un seul changement de paragraphe, il n'y a pas d'espace vertical parasite); à l'inverse, dans un logiciel wysiwyg, on ne peut s'autoriser à sauter "trop" de lignes, des "blancs" parasites en début de ligne, etc. Accepter les retour-chariot, à la rigueur, c'est bon pour les éditeurs Wysiwyg; et encore, tous ces logiciels les considèrent par défaut comme des changements de paragraphe, et non comme des retour à la ligne (faire l'essai dans n'importe quel soft de mise en page: après un "retour à la ligne" simple, on récupère une indentation de la première ligne, etc.).

7. Ecueil similaire avec les éditeurs Wysiwyg en ligne (rich text editors):
http://www.kevinroth.com/rte/demo.htm
MSIE a un comportement très propre mais limitatif: le retour à la ligne est systématiquement un changement de paragraphe, ce qui facilite un traitement propre de la mise en forme des paragraphes par la suite. Mozilla introduit des <br> successifs, moches comme tout, interdisant un traitement propre de la mise en forme (il n'y a plus, à priori, de paragraphes, dans un tel texte).

A*

Merci pour cette explication, j'avoue que je n'avais pas tout à fait compris
le but de la manoeuvre ...

Effectivement, les editeurs WYSIWYG procedent egalement par defaut par
paragraphe, mais on peut generalement configurer ces editeurs pour avoir les
"br" à la place.

Je n'ai pas encore pu tester "poesie" mais ca semble assez adapté au besoin,
non ?
Le plus simple est peut etre de l'utiliser systematiquement.

Sinon j'ai posté une petite contrib sur un editeur WYSIWYG (FCKEditor
compatible uniquement IE, mais Txia a fait l'integration de HTMLArea,
compatible egalement Mozilla, on devrait completer l'article rapidement) pas
trop lourd à integrer et dont la barre d'outil est entierement configurable.
On peut donc le parametrer pour avoir les fameux "br" et ne laisser que la
mise en page standard (gras, souligné ...).
Je n'ai pas tésté les raccourcis typo de SPIP dedans (puces, cadres ...),
mais à priori, ils devraient continuer à marcher (sinon, ca ne doit pas etre
bien mechant à remettre).

Ca peut donc etre une solution mais ATTENTION, pour le moment, en
bidouillant un peu, un redacteur peut mettre du script dans sa page, il faut
donc au minimum passer un filtre antiscript dans les squelette ou
directement sur le contenu avant de l'enregistrer.

Bon courage ...

Hello,

Je comprend mieux maintenant les choix concernant la typographie. Merci Arno
pour ces explications.

Bon, ça n'empêche pas que ça m'embête toujours et que je voudrais qu'un saut
de ligne reste un saut de ligne...
J'ai beau tourner dans le code, pas moyen de trouver la fonction qui fait
ça... :frowning:

Une p'tite indication peut-être ? :slight_smile:

A+

Gilles

Hop, je me répond à moi même, non mais ! :slight_smile:

En fait, en réfléchissant 5 minutes de plus, j'ai trouvé une solution. Elle
n'est pas très élégante mais ça marche.
C'est tout bête, au lieu d'appliquer un filtre au niveau du squelette, je
l'applique au niveau de la partie privée. Je filtre le contenu du champ à
l'enregistrement de l'article et j'applique le filtre inverse lorsqu'il est
affiché ("\n"->"\n_ " et "\n_ " -> "\n"). Mes utilisateurs se serviront
ainsi d'une fonctionnalité de SPIP sans s'en rendre compte et je me
simplifie la vie. :wink:

A+ et bon we

Gilles