Déplacer les fonctions typographiques dans un plugin séparé #3324

Open
opened 7 years ago by rastapopoulos · 11 comments
Owner

La bonne gestion typographique est un domaine différent de la compilation de "balisage léger".

Textwheel s'occupe du balisage léger, ce que dans SPIP on appelle (un peu à tort quand même) "raccourcis typographiques".

Mais les fonctions de typo "fr" et "en" devraient être dans un plugin séparé, fourni en plugins-dist aussi. Et devraient alors être complètement supprimé à la fois de Textwheel et du reliquat qu'on trouve dans le noyau.

Il faut voir si les appels à ces fonctions doivent rester dans le core ou pas (par exemple en testant si ça existe avant d'appeler) ou bien si même les appels pourraient être déplacés dans ce plugin séparé (ce serait encore mieux !).

La bonne gestion typographique est un domaine différent de la compilation de "balisage léger". Textwheel s'occupe du balisage léger, ce que dans SPIP on appelle (un peu à tort quand même) "raccourcis typographiques". Mais les fonctions de typo "fr" et "en" devraient être dans un plugin séparé, fourni en plugins-dist aussi. Et devraient alors être complètement supprimé à la fois de Textwheel et du reliquat qu'on trouve dans le noyau. Il faut voir si les appels à ces fonctions doivent rester dans le core ou pas (par exemple en testant si ça existe avant d'appeler) ou bien si même les appels pourraient être déplacés dans ce plugin séparé (ce serait encore mieux !).
Fil commented 7 years ago
Collaborator

Quelques autres améliorations à faire (pas très difficile, mais pointilleux : faire des cas tests).

  1. toujours rendre les espaces insécables (même en anglais) quand l'espace est déjà présente (a ! => a~!)

  2. en français-français, ajouter les espaces insécables, mais pas en français-suisse (enfin, différemment)
    http://fr.wikipedia.org/wiki/Comparatif_des_différents_codes_typographiques_francophones#Diff.C3.A9rences_entre_les_typographies_fran.C3.A7aise_et_suisse

  3. remplacer les insécables qui vont bien par des fines (en option avec réglage ou define). Le code est déjà fait, il suffit de l'intégrer (avec les tests idoines) cf. http://core.spip.org/issues/1461

Quelques autres améliorations à faire (pas très difficile, mais pointilleux : faire des cas tests). 1. toujours rendre les espaces insécables (même en anglais) quand l'espace est déjà présente (a ! => a~!) 2. en français-français, ajouter les espaces insécables, mais pas en français-suisse (enfin, différemment) http://fr.wikipedia.org/wiki/Comparatif_des_différents_codes_typographiques_francophones#Diff.C3.A9rences_entre_les_typographies_fran.C3.A7aise_et_suisse 3. remplacer les insécables qui vont bien par des fines (en option avec réglage ou define). Le code est déjà fait, il suffit de l'intégrer (avec les tests idoines) cf. http://core.spip.org/issues/1461
Poster
Owner
There is no content yet.

Encore faut-il que l'on puisse distinguer le français-français du français-suisse ce qui n'est pas le cas aujourd'hui.

Encore faut-il que l'on puisse distinguer le français-français du français-suisse ce qui n'est pas le cas aujourd'hui.

oui, d'autant plus que pour vivre en suisse romande, j'ai l'impression que se calque de plus en plus sur le français de l'intérieur. Sauf pour la monnaie où on met - pour dire CHF. Mais rien à voir avec notre problème

oui, d'autant plus que pour vivre en suisse romande, j'ai l'impression que se calque de plus en plus sur le français de l'intérieur. Sauf pour la monnaie où on met - pour dire CHF. Mais rien à voir avec notre problème
Owner

Version cible mise à 4.1

**Version cible mise à 4.1**
Owner

Le plugin orthoypo https://plugins.spip.net/orthotypo semble être un bon candidat pour recevoir tout ça non ?

Le plugin orthoypo https://plugins.spip.net/orthotypo semble être un bon candidat pour recevoir tout ça non ?
Poster
Owner

Tu veux dire du coup à la fin passer orthotypo en plugins dist ? Il me parait fournir quand même pas mal de choses plus spécifiques, mais peut-être… À la base je pensais plutôt vraiment que un plugin dédié à la "typo par langue", comme ce qu'on a mais juste enlevé du core.

Tu veux dire du coup à la fin passer orthotypo en plugins dist ? Il me parait fournir quand même pas mal de choses plus spécifiques, mais peut-être… À la base je pensais plutôt vraiment que un plugin dédié à la "typo par langue", comme ce qu'on a mais juste enlevé du core.
Owner

Ben je pensais à celui là car c'est son périmètre d'action, mais j'ai aussi de douloureux souvenirs d'orthotypo qui s’incruste à tort dans certaines balises ou dans des mails de notification, donc oui il serait certainement plus sage de commencer par déporter le code du core dans un plugin à part.

Ben je pensais à celui là car c'est son périmètre d'action, mais j'ai aussi de douloureux souvenirs d'orthotypo qui s’incruste à tort dans certaines balises ou dans des mails de notification, donc oui il serait certainement plus sage de commencer par déporter le code du core dans un plugin à part.
Owner

Suite à un «bug» de typo() dès lors qu’on utilise déjà des espaces insécables UTF-8 en amont (cf: #4895), j’ai regardé un peu ça.

J’ai trouvé le code peu clair, différent entre ecrire/typographie/fr et textwheel/typographie/fr sans forcément comprendre pourquoi, et aussi il me semble y avoir un problème avec le résultat :

SPIP colle un espace insécable au lieu d’un espace fine insécable devant ?, ! ou ;, ce qui n’est pas ce qu’on attendrait d’une typographie parfaite.

Typopographer (WIP)

J’ai commencé un truc qui s’appuie sur JoliTypo, que j’ai du adapter un peu.

Une librairie «indépendante» de SPIP
https://gitlab.com/spipremix/typography/

Une librairie pour SPIP (note qu’à cette heure, je suis pas encore convaincu du code de celle là, ou si j’en fais un plugin SPIP directement).
https://gitlab.com/spipremix/typographer

Usage :

# squelettes/typographie/fr.php
<?php

use SpipRemix\Typographer\Typographer;

function typographie_fr(string $text) : text {
    $typographer = new Typographer('fr');
    $fixed = $typographer->fix($text);
    #$fixed = html_entity_decode($fixed);
    return $fixed;
}

Des questionnements sur le HTML

La librairie amène d’autres questions.

En entrée elle attend du HTML valide pour fonctionner correctement (sinon il faut utiliser la méthode fixString($text) mais qui risque de casser le code html s’il y en a).

En sortie, tout est encodé, même les accents (é devient &eacute;), ce que ne faisait pas SPIP.

Avec Émile est > à un ami <strong>fort</strong> mais < moi ou > toi!
On obtient, en appelant typo()

  • Avec la typo SPIP (fr) :
    Émile est > à un ami <strong>fort</strong> mais &lt; moi ou > toi&nbsp;!
  • Avec Typographer (fix) :
    &Eacute;mile est &gt; &agrave; un ami <strong>fort</strong> mais toi&#8239;!
  • Avec Typographer (fixString) en utf8 correct :
    Émile est > à un ami <strong>fort</strong> mais &lt; moi ou > toi !

Donc là, dans fix() on voit que < moi ou > (un faux tag donc) a disparu.

Ordre de echapper_faux_tags()

Mais notons que ça dépend aussi de l’ordre d’appel dans typo() de echapper_faux_tags.

Si on inverse avec la correction typo (ou si on la double avant et après) :

+ $letexte = echapper_faux_tags($letexte);
$letexte = corriger_typo($letexte);
- $letexte = echapper_faux_tags($letexte);

On obtient Avec Typographer (fix) :
&Eacute;mile est &gt; &agrave; un ami <strong>fort</strong> mais &lt; moi ou &gt; toi&#8239;!

Qui a bien conservé le < moi ou > toi intacte du coup.

Les quotes

JoliTypo arrive à mieux à gérer de jolis guillemets ", à l’intérieur d’autres guillements, contrairement à OrthoTypo ; mais si ce n’est pas parfait en FR (toujours des « ou » utilisés, et nécessite d’avoir un sous-node html.

Exemple avec :

Il dit qu'une "âme «hantait» les dimanches"
Il dit qu'une «âme "hantait" les dimanches»
Il dit qu'une "âme <em>"hantait"</em> les <strong>"dimanches"</strong>"

Devient :

Il dit qu&rsquo;une &laquo;&nbsp;&acirc;me &laquo;&nbsp;hantait&nbsp;&raquo; les dimanches&nbsp;&raquo;
Il dit qu&rsquo;une &laquo;&nbsp;&acirc;me &laquo;&nbsp;hantait&nbsp;&raquo; les dimanches&nbsp;&raquo;
Il dit qu&rsquo;une &laquo;&nbsp;&acirc;me <em>&laquo;&nbsp;hantait&nbsp;&raquo;</em> les <strong>&laquo;&nbsp;dimanches&nbsp;&raquo;</strong>&nbsp;&raquo;

Soit un utf8 :

Il dit qu’une « âme « hantait » les dimanches »
Il dit qu’une « âme « hantait » les dimanches »
Il dit qu’une « âme <em>« hantait »</em> les <strong>« dimanches »</strong> »

Ça ne gère donc pas des guillemets interieurs qui deviendraient quelque chose comme “ et ” en français.
Cf Todo JoliTypo

Suite à un «bug» de typo() dès lors qu’on utilise déjà des espaces insécables UTF-8 en amont (cf: #4895), j’ai regardé un peu ça. J’ai trouvé le code peu clair, différent entre ecrire/typographie/fr et textwheel/typographie/fr sans forcément comprendre pourquoi, et aussi il me semble y avoir un problème avec le résultat : SPIP colle un espace insécable au lieu d’un espace fine insécable devant `?`, `!` ou `;`, ce qui n’est pas ce qu’on attendrait d’une typographie parfaite. ## Typopographer (WIP) J’ai commencé un truc qui s’appuie sur [JoliTypo](https://github.com/jolicode/JoliTypo/), que j’ai du adapter un peu. Une librairie «indépendante» de SPIP https://gitlab.com/spipremix/typography/ Une librairie pour SPIP (note qu’à cette heure, je suis pas encore convaincu du code de celle là, ou si j’en fais un plugin SPIP directement). https://gitlab.com/spipremix/typographer Usage : ```php # squelettes/typographie/fr.php <?php use SpipRemix\Typographer\Typographer; function typographie_fr(string $text) : text { $typographer = new Typographer('fr'); $fixed = $typographer->fix($text); #$fixed = html_entity_decode($fixed); return $fixed; } ``` ### Des questionnements sur le HTML La librairie amène d’autres questions. En entrée elle attend du HTML valide pour fonctionner correctement (sinon il faut utiliser la méthode `fixString($text)` mais qui risque de casser le code html s’il y en a). En sortie, tout est encodé, même les accents (`é` devient `&eacute;`), ce que ne faisait pas SPIP. Avec `Émile est > à un ami <strong>fort</strong> mais < moi ou > toi!` On obtient, en appelant `typo()` - Avec la typo SPIP (fr) : `Émile est > à un ami <strong>fort</strong> mais &lt; moi ou > toi&nbsp;!` - Avec Typographer (fix) : `&Eacute;mile est &gt; &agrave; un ami <strong>fort</strong> mais toi&#8239;!` - Avec Typographer (fixString) en utf8 correct : `Émile est > à un ami <strong>fort</strong> mais &lt; moi ou > toi !` Donc là, dans `fix()` on voit que `< moi ou >` (un faux tag donc) a disparu. ### Ordre de echapper_faux_tags() Mais notons que ça dépend aussi de l’ordre d’appel dans `typo()` de `echapper_faux_tags`. Si on inverse avec la correction typo (ou si on la double avant et après) : ```diff + $letexte = echapper_faux_tags($letexte); $letexte = corriger_typo($letexte); - $letexte = echapper_faux_tags($letexte); ``` On obtient Avec Typographer (fix) : `&Eacute;mile est &gt; &agrave; un ami <strong>fort</strong> mais &lt; moi ou &gt; toi&#8239;!` Qui a bien conservé le `< moi ou > toi` intacte du coup. ### Les quotes JoliTypo arrive à mieux à gérer de jolis guillemets `"`, à l’intérieur d’autres guillements, contrairement à OrthoTypo ; mais si ce n’est pas parfait en FR (toujours des `«` ou `»` utilisés, et nécessite d’avoir un sous-node html. Exemple avec : ``` Il dit qu'une "âme «hantait» les dimanches" Il dit qu'une «âme "hantait" les dimanches» Il dit qu'une "âme <em>"hantait"</em> les <strong>"dimanches"</strong>" ``` Devient : ``` Il dit qu&rsquo;une &laquo;&nbsp;&acirc;me &laquo;&nbsp;hantait&nbsp;&raquo; les dimanches&nbsp;&raquo; Il dit qu&rsquo;une &laquo;&nbsp;&acirc;me &laquo;&nbsp;hantait&nbsp;&raquo; les dimanches&nbsp;&raquo; Il dit qu&rsquo;une &laquo;&nbsp;&acirc;me <em>&laquo;&nbsp;hantait&nbsp;&raquo;</em> les <strong>&laquo;&nbsp;dimanches&nbsp;&raquo;</strong>&nbsp;&raquo; ``` Soit un utf8 : ``` Il dit qu’une « âme « hantait » les dimanches » Il dit qu’une « âme « hantait » les dimanches » Il dit qu’une « âme <em>« hantait »</em> les <strong>« dimanches »</strong> » ``` Ça ne gère donc pas des guillemets interieurs qui deviendraient quelque chose comme “ et ” en français. Cf [Todo JoliTypo](https://github.com/jolicode/JoliTypo/blob/master/TODO.md#fr-fr)
Owner

Les espaces insécables au lieu des fines, c'est juste historique parce que pendant longtemps les espaces fines n'étaient pas correctement rendus par tous les navigateurs.

https://spip-dev.rezo.narkive.com/weMwuXbA/typo-espace-insecable-ou-espace-fine

Je suppose que ce n'est plus un sujet, mais personne n'a pris le temps de changer ça en faisant tous les tests qui vont bien pour pas faire de boulette...

Notamment je lis ici
https://www.antidote.info/fr/blogue/enquetes/pour-des-espaces-insecables-impeccables
en bas de page

Mise à jour (2017). L’espace fine fait partie de la norme Unicode ; malheureusement, certains jeux de caractères ne la fournissent pas, et certains logiciels la traitent mal

À défaut d’espace fine, on recommande en Europe francophone d’utiliser l’espace insécable habituelle, tandis qu’au Québec on recommande plutôt de ne pas mettre d’espace du tout.

En Suisse, on adopte souvent la même solution de remplacement qu’au Québec.

Alors qu'ici je lis https://www.typofute.com/l_espace_fine_insecable_dans_les_documents_html

Dans les documents HTML, l’exemple le plus connu d’espace insécable est l’entité : «   », celle-ci a les mêmes propriétés que l’espace régulière, avec l’avantage de garder sur une même ligne les caractères étant de chaque côté. Pour l’espace fine, l’entité «   » est supportée par la plupart des fureteurs récents. Mais l’entité «   » est sécable, ce qui veut dire qu’en fin de ligne les caractères suivants seront poussés à la ligne suivante.

S’il y a bien une espace difficile à reproduire sur Internet, c’est bien l’espace fine insécable. Celle-ci n’est tout simplement pas définie dans la norme Unicode. Alors que plusieurs opteront pour l’utilisation de l’espace insécable ordinaire «   », ce n’est pas la bonne solution.

Heureusement, Unicode définit le « NARROW NO-BREAK SPACE », utilisant l’entité numérique : «   ». Cette espace étroite est insécable et peut être utilisée à la perfection comme espace fine insécable dans tout document HTML.

En typographie soignée, on prendra donc soin d’utiliser l’entité «   » comme espace fine insécable.

Et enfin une dernière référence
https://crowdagger.github.io/textes/articles/heuristique.html
ou elle explique comment tout bien faire avec le thin insécable, mais fini avec un addendum comme quoi ça foire chez certains lecteurs de son blog, et conclue en fallback sur
<span style = "white-space: nowrap;">&#8201;</span> comme la meilleure solution
ce qui revient peu ou prou à ce qui était proposé dans #1461
avec l'inconvénient que ça saute sur les filtres |texte_brut ou autre...

Et du coup le mieux est sans doute le hack originel de #1461 : mettre un espace insécable dans un span avec un style pour le réduire en taille, ce qui permet en fallback d'un filtre qui supprime les tags html de se retrouver avec un insécable ce qui est mieux qu'un demi-espace qui tombe...

BREF c'est pas si simple, même en 2021 :p

Les espaces insécables au lieu des fines, c'est juste historique parce que pendant longtemps les espaces fines n'étaient pas correctement rendus par tous les navigateurs. https://spip-dev.rezo.narkive.com/weMwuXbA/typo-espace-insecable-ou-espace-fine Je suppose que ce n'est plus un sujet, mais personne n'a pris le temps de changer ça en faisant tous les tests qui vont bien pour pas faire de boulette... Notamment je lis ici https://www.antidote.info/fr/blogue/enquetes/pour-des-espaces-insecables-impeccables en bas de page > Mise à jour (2017). L’espace fine fait partie de la norme Unicode ; malheureusement, certains jeux de caractères ne la fournissent pas, et certains logiciels la traitent mal > À défaut d’espace fine, on recommande en Europe francophone d’utiliser l’espace insécable habituelle, tandis qu’au Québec on recommande plutôt de ne pas mettre d’espace du tout. > En Suisse, on adopte souvent la même solution de remplacement qu’au Québec. Alors qu'ici je lis https://www.typofute.com/l_espace_fine_insecable_dans_les_documents_html > Dans les documents HTML, l’exemple le plus connu d’espace insécable est l’entité : « &nbsp; », celle-ci a les mêmes propriétés que l’espace régulière, avec l’avantage de garder sur une même ligne les caractères étant de chaque côté. Pour l’espace fine, l’entité « &thinsp; » est supportée par la plupart des fureteurs récents. Mais l’entité « &thinsp; » est sécable, ce qui veut dire qu’en fin de ligne les caractères suivants seront poussés à la ligne suivante. > > S’il y a bien une espace difficile à reproduire sur Internet, c’est bien l’espace fine insécable. Celle-ci n’est tout simplement pas définie dans la norme Unicode. Alors que plusieurs opteront pour l’utilisation de l’espace insécable ordinaire « &nbsp; », ce n’est pas la bonne solution. > > Heureusement, Unicode définit le « NARROW NO-BREAK SPACE », utilisant l’entité numérique : « &#8239; ». Cette espace étroite est insécable et peut être utilisée à la perfection comme espace fine insécable dans tout document HTML. > > En typographie soignée, on prendra donc soin d’utiliser l’entité « &#8239; » comme espace fine insécable. Et enfin une dernière référence https://crowdagger.github.io/textes/articles/heuristique.html ou elle explique comment tout bien faire avec le thin insécable, mais fini avec un addendum comme quoi ça foire chez certains lecteurs de son blog, et conclue en fallback sur `<span style = "white-space: nowrap;">&#8201;</span>` comme la meilleure solution ce qui revient peu ou prou à ce qui était proposé dans https://git.spip.net/spip/spip/issues/1461#issuecomment-12881 avec l'inconvénient que ça saute sur les filtres |texte_brut ou autre... Et du coup le mieux est sans doute le hack originel de #1461 : mettre un espace insécable dans un span avec un style pour le réduire en taille, ce qui permet en fallback d'un filtre qui supprime les tags html de se retrouver avec un insécable ce qui est mieux qu'un demi-espace qui tombe... BREF c'est pas si simple, même en 2021 :p
Owner

Alors dans JoliTypo, c’est des Narrow No-Break Space qui sont donc utilisés comme espace fines.

Alors dans JoliTypo, c’est des `Narrow No-Break Space` qui sont donc utilisés comme espace fines.
Sign in to join this conversation.
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.