[spip-dev] Guillemets "simples", modif barre, <cadre>

Dev
1

Salut,

Petites modifs, dont deux me semble importantes:

- Important, j'ai ajouté la gestion des guillemets "simples" ouvrants et fermants; en typo française, ces guillements sont utilisés notamment à l'intérieur d'une citation («Monsieur Machin cria: "Stop!".»); dans les autres langues (qui n'utilisent pas les guillemets français), ils sont indispensables. Notez bien qu'il ne s'agit pas des guillemets généralement utilisés en informatique, mais qu'ils sont bien ouvrants et fermants. Ce petit détail permet d'affiner la gestion typographique dans SPIP.

Note: si on voulait, puisque ces guillemets sont ouvrants et fermants, on pourrait passer un coup de correction typographique pour sucrer les espaces trÚs souvent ajoutés à l'intérieur de ce type de guillemets (beaucoup de gens sont persuadés qu'il faut " mettre des espaces " à l'intérieur de ce type de guillemets, ce qui est une horreur...). On ne peut pas faire cette correction avec les guillemets simples du clavier (touche "3"), bicoz on ne sait pas lequel ouvre et lequel ferme; mais avec ceux-là on pourrait.

- Ajouté deux boutons dans la barre de raccourcis: espace insécable ("une" espace, en typographie) et ces fameux guillemets simples ouvrant et fermant. Pour la présence de ce deuxiÚme bouton, il s'agit à la fois d'en faciliter l'accÚs à ceux qui ne les trouvent pas sur leur clavier, mais aussi d'insister sur leur existence (la plupart des gens ne les utilisent pas, non seulement parce qu'ils ne les trouvent pas sur le clavier, mais aussi parce qu'ils ne voient pas l'utilité d'une typo fine; en affichant le bouton, comme les guillemets français, ça encourage un comportement typographique plus élégant).

- Important aussi, corrigé le problÚme des forums publics qui interdisait l'utilisation du raccourci <cadre></cadre> qui permet de présenter du code dans un élément de formulaire, ce qui garantit une mise en page avec conservation des tabulations de début de ligne et simplifie énormément le copier-coller. Pas de raccourci dans la barre pour ça, parce que l'utilité est trÚs spécifique à certains sites (par exemple, échanger des trucs sur spip.net ou sur un site consacré au C++).

ARNO*

2

Je viens de modifier le comportement des petits boutons d'aide et des fleches de dépliage quand javascript est désactivé: en effet, (Mozilla) le <noscript> introduit un retour à la ligne.

Parce que, ce qui était affiché avec javascript:

   > Logo de la rubrique [?]

devenait, sans javascript:

   V
   Logo de la rubrique
   [?]

Sur certaines pages, cela devenait proprement insupportable (édition des articles, y'avait des retours à la ligne dans tous les sens).

Inconvénient: sans javascript, plus d'affichage des petits boutons d'aide en ligne. Mais au moins les pages sont utilisables avec un graphisme proche du "avec javascript"...

ARNO*

3

Nouvelle correction: dans les articles, la fonction "corriger_caractères" sucrait purement et simplement les guillements simples ouvrants et fermants.

- Du coup, argument en faveur de la barre des raccourcis qui permet de "taper" des caractères normaux en typo, mais mal connus des utilisateurs: la fonction "corriger_caracteres" indique en remarque qu'il s'agit de sucrer des caractères "dégoutants utilisés par les Windowseries". Sauf que, justement, ce sont des caractères utilisés quotidiennement en PAO pour avoir une typo correcte. Et ça, je le fais sur Mac (y'aurait-il des machintosheurs qui ne connaissent pas leur clavier? :-)))

- J'ai laissé les autres filtres, mais c'est problématique...

    - Les anglosaxons n'utilisant pas les «guillemets français», ils utilisent les guillemets simples pour les “citations”. Mais à l'intérieur des citations, il me semble bien qu'ils utilisent ce truc bizarre qui est une sorte d'apostrophes ouvrante et fermante. Or "corriger_caractères" sucre ça.

    - Seulement, il n'est pas impossible que plusieurs logiciels de saisie utilisent l'apostrophe fermante (en forme de goutte d'eau) à la place de l'apostrophe "droite" (celle utilisée en informatique). Word fait p'têt bien ça. Du coup, sans le filtre, on obtient des textes qui utilisent cette apostrophe fermante. Cela dit, ça ne me choque pas, parce que c'est justement un truc pénible du HTML: les apostrophes dans le texte sont hideuses (droites).

    - Une solution serait d'ajouter à notre panoplie de corrections typographiques le remplacement, dans "propre()", de l'apostrophe droite par la "bonne" apostrophe en forme de goutte d'eau, nettement plus zolie (l'effet est particulièrement remarquable dans les titres en gros caractères). Sauf à l'intérieur des codes informatiques (<code>, <cadre>, <html>...) comme on le fait déjà.

    - Les autres caractères corrigés sont les traits longs, qui existent en typo. Plutôt que de les interdire, est-ce qu'on ne devrait pas plutôt les lier au "nouveau" raccourci introduit par Antoine avec les deux tirets en début de ligne? Ce qui permettrait d'obtenir le même effet, soit en tapant deux tirets, soit en allant directement taper le bon caratère sur son clavier.

ARNO*

4

Salut,

Je viens d'introduire le changement d'affichage de l'apostrophe (faudrait tester).

- L'apostrophe devient, partout (sauf code informatique), une apostrophe typographiquement correcte (en forme de goutte d'eau). Pour que ça s'applique partout (y compris titres) et que ça ne perturbe pas les inserts d'images et documents joints, le remplacement se fait dans la fonction typo (et non propre).

- Les guillemets de deuxiÚme niveau 'anglosaxons', ouvrant et fermant, sont acceptés.

- Ces guillemets apparaissent dans la barre de raccourcis, sauf en français (où ils ne sont pas utilisés).

Je l'ai installé sur le Scarabée, et c'est épatant: la typo est _enfin_ au niveau de ce que j'en attendais! On peut voir ça par exemple sur l'article, où tous les dialogues sont présentés entre guillemets français avec des mots entre guillemets de second niveau.
http://www.scarabee.com/article155.html

L'apostrophe du titre était évidemment la plus moche, puisque la plus grosse. Dans le texte, l'affichage se faisant en georgia (genre Times), on a bien les goutelettes (si nécessaire, imprimez pour voir un peu plus la différence). Dans la fin du texte, il y avait un véritable horreur: dans la citation, le personnage évoque «la notion d'"axe du mal"»; à l'écran, ça apparaissait sous le forme: «d'''axe du mal''».

ARNO*

5

Qui a dit que : «les voies du Seigneur étaient impénétrables» ? :wink:

ARNO* a écrit :

6

ARNO* a écrit:

j'ai ajouté la gestion des guillemets "simples" ouvrants et
fermants; en typo française, ces guillements sont utilisés notamment à
l'intérieur d'une citation («Monsieur Machin cria: "Stop!".»);

D¹abord, bravo pour l'apostrophe. Je commençais à désespérer de voir un jour
ce signe typographique si maltraité (particulièrement sur Internet)
réapparaître.

Pour ce qui est des guillemets à l'intérieur de guillemets, en typographie
française n'utilise-t-on pas plutôt les chevrons simples: « Monsieur Machin
cria : Ð Stop ! ð. »; à ne pas confondre, évidemment, avec < (plus petit
que) et > (plus grand que).

En anglais, même logique: les guillemets simples ouvrants et fermants à
l'intérieur des guillemets doubles ouvrants et fermants.

Pour ce qui est de la barre des raccourcis, il y a un raccourci que
j'aimerais bien y voir: la changement de ligne (barre de soulignement suivi
d'un espace en début de ligne). Chez nous, étrangement, c'est le raccourci
le mal maîtrisé par les rédacteurs.

André V.

7

Re,

> Pour ce qui est de la barre des raccourcis, il y a un raccourci que
> j'aimerais bien y voir: la changement de ligne (barre de soulignement suivi
> d'un espace en début de ligne). Chez nous, étrangement, c'est le raccourci
> le mal maîtrisé par les rédacteurs.
  
  => Je confirme (en particulier dans l'usage des forums cela conduit certains utilisateurs à systématiser le saut de ligne... pour être sûr d'avoir un retour à la ligne !)

J.Chatignoux

8

Merde,

MS Entourage a bousillé mes beaux chevrons simples.

Il s'agit des entités &lsaquo; et &rsaquo; pour les guillemets simples
français et &lsquo; et &rsquo; pour les guillemets simples anglais.

AV

9

Bonjour,

française n'utilise-t-on pas plutôt les chevrons simples: « Monsieur Machin
cria : Ð Stop ! ð. »; à ne pas confondre, évidemment, avec < (plus petit
que) et > (plus grand que).

Non, pas en typographie française. Soit on utilise " " (courbes, bien sûr) ou on maintient l'utilisation de « et » (de moins en moins courant).

En anglais, même logique: les guillemets simples ouvrants et fermants à
l'intérieur des guillemets doubles ouvrants et fermants.

Non, en anglais britannique, c'est ' " " '. En anglais étatsunien, " ' ' ".

Gilles.

10

@ Arno* <arno@scarabee.com> :

Petites modifs, dont deux me semble importantes:

- Important, j'ai ajouté la gestion des guillemets "simples" ouvrants et
fermants;

Attention, ces caractères n'existent proprement que si tu es en utf-8...
sinon ils seront représentés, dans la base, sous la forme &#039; etc...

Par ailleurs, la toolbar n'est pas internationalisable ; il faudra donc la
corriger en ce sens, ou la supprimer de SPIP. :o)
Et il faut la rendre désactivable, si vous tenez à la garder (perso, je n'en
veux pas sur mes sites).

-- Fil

11

Non, non, ne fais pas n'importe quoi ! corriger_caracteres() n'a de sens
qu'en iso-8859-1, qui était notre référence à l'époque : là, les titrets
longs devenaient des mdash et ndash que beaucoup de navigateurs ne
comprenaient pas, et les apostrophes simples ouvrantes et fermantes de
Windows devenaient des 2 et 3 en exposant...

Si on décide de passer en utf-8 par défaut, cette fonction a beaucoup moins
d'intérêt, et en effet elle va plomber tes joliessses typo.

Sur cette question des charsets, il est clair que SPIP a démarré avec les
"standards de 1999", et que ça a beaucoup évolué depuis :wink:

Donc, pour modifier corriger_caractères(), je pense (il faut voir plus
précisément) qu'il suffit de tester le charset avant de faire les
corrections.

Quant à filtrer ' vers l'apostrophe jolie, ça me paraît être plus une
affaire de filtre typo() que de corriger_caracteres() (une fonction qui
nettoie ce qui va entrer dans la base).

@ Arno* <arno@scarabee.com> :

Nouvelle correction: dans les articles, la fonction "corriger_caractères"
sucrait purement et simplement les guillements simples ouvrants et
fermants.

-- Fil

12

Donc, pour modifier corriger_caractères(), je pense (il faut voir plus
précisément) qu'il suffit de tester le charset avant de faire les
corrections.

En fait c'est bien ce qui est fait. La solution la meilleure, concernant
ton site scarabee, serait de le passer en utf-8. Et le besoin évident est
posé : comment transformer tout un site en utf-8 (sans passer par un export
/ iconv / import un peu hors de portée des utilisateurs lambda) => on
pourrait imaginer une table temporaire (objet, id, charset-depart,
charset-arrivee) qu'on remplit avec tous les objets existants, et qu'on vide
tranquillement, en boucle, jusqu'à complétion du programme (puis suppression
de la table une fois qu'elle est vide).

Quant à filtrer ' vers l'apostrophe jolie, ça me paraît être plus une
affaire de filtre typo() que de corriger_caracteres() (une fonction qui
nettoie ce qui va entrer dans la base).

Ah bin, c'est ce que tu as fait :wink:

-- Fil

13

Non, non, ne fais pas n'importe quoi ! corriger_caracteres() n'a de sens
qu'en iso-8859-1, qui était notre référence à l'époque : là , les titrets
longs devenaient des mdash et ndash que beaucoup de navigateurs ne
comprenaient pas, et les apostrophes simples ouvrantes et fermantes de
Windows devenaient des 2 et 3 en exposant...

Si on décide de passer en utf-8 par défaut, cette fonction a beaucoup moins
d'intérêt, et en effet elle va plomber tes joliessses typo.

Sur cette question des charsets, il est clair que SPIP a démarré avec les
"standards de 1999", et que ça a beaucoup évolué depuis :wink:

- Le problÚme, c'est que corriger_caracteres() s'applique en amont de l'insertion dans la base de donneés; donc rien n'était conservé. Impossible d'utiliser les guillemets ouvrants et fermants simples.

- Je n'ai pas touché aux tirets, seulement aux apostrophes et guillemets ouvrants et fermants. Ces caractÚres existent en HTML et le comportement est le même que pour les guillemets français: c'est remplacé (en iso-machin uniquement?, en tout cas c'est la fonction qui se trouvait déjà dans SPIP) par les codes correspondants: l'apostrophe devient &rsquo;, les autres leur code unicode. (Le scarabée est sous iso-8859-1.)

Donc, pour modifier corriger_caractÚres(), je pense (il faut voir plus
précisément) qu'il suffit de tester le charset avant de faire les
corrections.

Je veux bien le croire :-))

Mais j'ai appliqué les mêmes fonctions/méthodes que pour les guillemets français, hein.

ARNO*

14

- Le problème, c'est que corriger_caracteres() s'applique en amont de
l'insertion dans la base de donneés; donc rien n'était conservé. Impossible
d'utiliser les guillemets ouvrants et fermants simples.

Impossible, sur iso-8859-1, oui. Mais bon, tu utilises un charset limité, et
tu veux y faire entrer des caractères compliqués : ça n'a pas que des
avantages.

- Je n'ai pas touché aux tirets, seulement aux apostrophes et guillemets
ouvrants et fermants. Ces caractères existent en HTML et le comportement
est le même que pour les guillemets français: c'est remplacé (en iso-machin
uniquement?, en tout cas c'est la fonction qui se trouvait déjà dans SPIP)
par les codes correspondants: l'apostrophe devient &rsquo;, les autres leur
code unicode. (Le scarabée est sous iso-8859-1.)

Une quesrtion : &rsquo; est-il compris par tous les navigateurs ? A une
époque même les &raquo; et &emdash; posaient problème, c'est pour ça qu'on
nettoyait. Peut-être que ça n'est plus du tout nécessaire, mais ça mérite
des tests un peu poussés.

Mais j'ai appliqué les mêmes fonctions/méthodes que pour les guillemets
français, hein.

C'est là qu'il y a un problème que je n'avais pas vu tout à l'heure :
l'ajout, dans typo(), de la correction "' => &rsquo;" va faire foirer tous
les sites existants qui ont, dans leurs articles, des boutrs de html
non-échappés (qu'on pouvait auparavant laisser tels quels, parce qu'ils
passaient bien... et je ne m'en suis pas privé, comme d'autres, je suppose):
si on applique ta modif telle quelle, il faudra passer sur toute la base et
repérer les cas litigieux : <a href='url'>toto</a> devrait maintenant être
<html><a href='url'></html>toto</a> ? A mon avis ça ne va pas ; la
correction en question devrait s'appliquer plus finement (ou alors, mais ça
serait beaucoup moins bien, être désactivable).

-- Fil

15

Une quesrtion : &rsquo; est-il compris par tous les navigateurs ? A une
époque même les &raquo; et &emdash; posaient problème, c'est pour ça qu'on
nettoyait. Peut-être que ça n'est plus du tout nécessaire, mais ça mérite
des tests un peu poussés.

Déjà, un bon point : ça marche avec 'lynx', ce qui est (pour moi) un critère
essentiel, vu ce que je fais :wink:

-- Fil

16

Grumpf...

- Pour les <a href='monsite.com'> codés en HTML, c'est déjà échappé, no problemo.

- Pour les autres, yep ça déconne.

Je regarde ça.

ARNO*

17

IMPORTANT

Je viens d'uploader une modif: dans la fonction des échappements (inc_texte.php3), remplacer l'échappemet des <a ...> par un échappement de tous les codes HTML (<...>).

- Cela résoud le problÚme des apostrophes, qui ne s'appliquent ainsi pas aux tags HTML (<img src='puce.gif').

- Cela résoud aussi les difficultés liées à d'autres tags, notamment contenant des styles (<span style="color: red;">) (là c'est le point- virgule qui était corrigé).

- Sauf erreur, cela permet de se passer de <html></html> quand on veut balancer du HTML dans son texte.

- Inconvénient, cela peut créer "beaucoup" plus d'éléments échappés (bon, uniquement dans les cas où les gens balancent plein de HTML directement dans les articles). Est-ce que ça ralentit le traitement? Bicoz, en revanche, le critÚre de l'ereg est beaucoup plus simple (plus "rapide" à traiter?).

ARNO*

18

Autre problÚme récurrent: l'utilisation de l'italique dans les titres (notamment). C'est vraiment un besoin, le problÚme se pose réguliÚrement. Un titre façon Samizdat, genre "Le journaliste du {Monde} répond aux critiques de ses lecteurs", il faut passer des <i></i> dans le titre, c'est pas tip-top.

En passant le traitement de l'italique dans la symple "typo()", on résoudrait ce problÚme fréquent. (Pas les autres raccourcis, puisqu'ils n'ont pas d'utilité dans les titres, surtitre, etc.)

ARNO*

19

En revanche, problÚme avec Netscape 4.08 (pfiou - c'est ce que j'ai trouvé de plus vieux): effectivement l'apostrophe en code HTML n'était pas comprise. Les autres symboles étant tous codés selon le code UNICODE, j'ai fait la même chose dans le replace de l'apostrophe, en utilisant &#146; (et non &rsquo;) et ça résoud le problÚme. Affichage nickel sous Netscape 4.08 désormais.

(En revanche, je confirme que l'espace privé, au bout de deux pages, hé ben Netscape quitte spontanément...)

ARNO*

20

@ Arno* <arno@scarabee.com> :

Je viens d'uploader une modif: dans la fonction des échappements
(inc_texte.php3), remplacer l'échappemet des <a ...> par un échappement de
tous les codes HTML (<...>).
.../...
- Inconvénient, cela peut créer "beaucoup" plus d'éléments échappés (bon,
uniquement dans les cas où les gens balancent plein de HTML directement
dans les articles). Est-ce que ça ralentit le traitement? Bicoz, en
revanche, le critère de l'ereg est beaucoup plus simple (plus "rapide" à
traiter?).

Je ne pense pas que ça pose un problème ; et ça aura l'avantage de
simplifier le code, ce qui est bon (tm).

En passant le traitement de l'italique dans la symple "typo()", on
résoudrait ce problème fréquent. (Pas les autres raccourcis, puisqu'ils
n'ont pas d'utilité dans les titres, surtitre, etc.)

Oui, je crois même que c'est dans la TODO ({italiques}, et {{gras}} : je
sais qu'on n'est pas censé mettre de gras dans les titres, mais ça permet de
garder une cohérence entre ces deux raccourcis, sinon on va avoir des
questions inutiles...)

-- Fil