suite à différents essais voilà où j'en suis sur les histoires de sauts de
ligne :
* un filtre post_autobr() capable de distinguer dans un flux les parties
SPIP à ne pas toucher (<code>...</code>), et les autres ; ce filtre peut
transformer les sauts de ligne simples soit en "\n_ " (le raccourci SPIP
pour forcer les sauts de ligne), soit en " " (les éliminer).
* Dans la partie ecrire/articles_edit.php3 (celle qui compose le texte pour
le mettre dans le <textarea>), on peut décider d'appliquer
post_autobr(..., " "), histoire de supprimer les sauts de ligne d'un
fichier source non normalisé. Pour l'instant, je ne le fais pas.
* Dans la partie ecrire/articles.php3 (celle qui réceptionne les données),
on peut à l'inverse appliquer post_autobr(..., "\n_ ") pour "prendre en
compte les sauts de ligne". (pour l'instant c'est en fonction de la case à
cocher installée dans articles_edit)
Du coup, le choix de les prendre en compte ou pas est un peu moins
problématique qu'avant : à la limite ça peut être au choix de l'utilisateur
(réglage perso), du webmestre (réglage global), ou à la demande (comme
maintenant).
L'avantage du "à la demande" c'est de permettre d'entrer très vite soit un
poème soit un texte copié-collé d'un mail, et d'appliquer le filtre en
fonction de la source. L'inconvénient c'est que ça ajoute une option de
saisie : alourdit l'interface, pour (presque) rien.
L'avantage du "à la demande" c'est de permettre d'entrer très vite
soit un poème soit un texte copié-collé d'un mail, et d'appliquer le
filtre en fonction de la source. L'inconvénient c'est que ça ajoute
une option de saisie : alourdit l'interface, pour (presque) rien.
Perso, jusqu'à présent, j'ai toujours tapé un <BR> quand j'en avais
besoin : spip l'interprète bien et c'est pas difficile à retenir
L'avantage du "à la demande" c'est de permettre d'entrer très vite
soit un poème soit un texte copié-collé d'un mail, et d'appliquer le
filtre en fonction de la source. L'inconvénient c'est que ça ajoute
une option de saisie : alourdit l'interface, pour (presque) rien.
Perso, jusqu'à présent, j'ai toujours tapé un <BR> quand j'en avais
besoin : spip l'interprète bien et c'est pas difficile à retenir
Claude
Oui mais <br> ne rentre pas dans la philo de SPIP, comment expliquer à un rédacteur qu'il ne peut pas faire un simple retour à la ligne?
Le but de cette modification c'est de faire un copié collé sans rien retoucher.
Modifs dans inc-texte et dans les feuilles de style:
- création d'un nouveau raccourci: <poesie></poesie>: le texte à l'intérieur de ce raccourci est affiché avec des retours à la ligne à chaque ligne;
- ce raccourci existe également en anglais: <poetry></poetry>
- du coup, création d'une "traduction" pour <cadre>: <frame> (on peut donc utiliser <frame></frame> en lieu et place de <cadre></cadre>
<poesie> fabrique un div contenant tout, avec pour classe "spip_poesie". Chaque ligne de texte à l'intérieur est à l'intérieur de son propre <div>. Ceci permet d'avoir un contrôle très fin sur la mise en page (par défaut: indentation négative de la première ligne de chaque vers, ce qui permet d'afficher "propre" les vers plus longs que la largeur de la colonne de texte).
On peut donc personnaliser la présentation avec les styles suivants:
div.spip_poesie {}
div.spip_poesie div {}
(par défaut: trait gris à gauche, et indentation négative de chaque première ligne des vers; on peut imaginer changer de taille, encadrer l'ensemble, etc.).
Note: en théorie, on devrait aussi pouvoir jouer avec un style:
div.spip_poesie div:first-line {}
mais ça semble très bugué dans les brouteurs.
Pour la présentation, ici, c'est un style personnalité, le texte apparaît minuscule; le style par défaut présente le texte dans la même taille que le texte courant.
-> Personnellement, je préfère respecter la syntaxe qu'on a utilisé jusqu'ici, ça simplifie tout de même le travail de mon neurone quand je veux modifier un style. :-))
