Mises en exposant - commentaires

Mises en exposant

Merci bien à vous pour vos réponse, du coup j'ai activé la lame 'Corrections automatiques' du Couteau-suisse et inséré l'instruction qui marche ok !

Reste la question du traitement de ce pauvre km2 par Exposants typographiques... on s'attend à ce qu'il soit pris en charge mais il doit y avoir des raisons.. En tout cas peut-être le signaler dans la doc ci-dessus (km2 n'étant pas rare).
Merci encore
Thomas

Mises en exposant

La lame « Exposants typographiques » du Couteau Suisse ne corrige pas « km2 » actuellement.

Mais il est possible d'utiliser un autre outil :
- « Corrections automatiques »
avec la ligne suivante :
(km2) = km²

La correction automatique utilisera les mêmes css des exposants typographiques.

Mises en exposant

Ah oui pardon j'ai confondu.
Je n'utilise pas couteau suisse mais https://contrib.spip.net/Ortho-typographie qui permet d'ajouter des règles perso.

Mises en exposant

Merci mais alors.. orthotypo.. le plugin ? A ajouter ?

Mises en exposant

Bonjour,
Tu peux ajouter une règle comme :
/km2/ = km²

dans la config du plugin en bas /ecrire/ ?exec=configurer_orthotypo

Mises en exposant

Bonjour,
Cas de « km2 » qui ne semble pas traité.. (alors que « m² » l'est bien..). J'ai essayé de modifier le typo_exposants.php (non surchargeable.. donc le fichiers original.. pas bien, je sais mais hélas que faire d'autre...?).

- Donc est-ce qu'il y a un problème car « km2 » devrait bien être traité ?
- Ou est-ce que c'est normal et dans ce cas là, quel serait le code à insérer dans typo_exposants.php pour que cela marche ?

Merci,
Thomas

Mises en exposant

Finalement, j'ai réussi à passer après le css du Couteau Suisse à intégrant la surcharge dans le fichier css surchargé d'un plugin (Bigfoot en l'occurence...)...
C'est pas très propre mais ça fonctionne...
En attendant d'avoir la mise à jour du plugin Ahuntsic avec ses fichiers de style compatibles avec Spip3.2.
Merci en tout cas pour ton aide.
Pb résolu.

Mises en exposant

Toute l'architecture du squelette doit être vérifiée.
Le fichier config_outils.php n'est pas surchargeable. Toute surcharge CSS doit être faite dans le dossier personnel du squelette, souvent squelettes/ effectivement.
La mention !important règle le problème des priorités CSS.

Mises en exposant

Mais cela doit être ajouté dans quel fichier pour que cela passe après le CS ?
En attendant de pouvoir régler ces variables dans l'administration du plugin, y a-t-il une possibilité de surcharger config_outils.php ? Dans quel répertoire du squelettes doit-on enregistrer la copie modifiée de ce fichier ?
Je rappelle que le fichier créé squelettes/css/perso.css ne passe pas après les css des plugins (en tout cas chez moi...).
Je soupçonne le plugin « Ahuntsic » de mettre le bazar depuis la mise à jour Spip3.2 et la refonte de la gestion des cascades css...

Mises en exposant

En effet, donc trois solutions :

1. placer les nouvelles définitions dans le squelette après celles du CS

2. ajouter une clause de priorité :

sup, sup.typo_exposants { vertical-align: 10% !important;
}

3. choisir une autre formulation, meilleure visuellement :

sup, sup.typo_exposants { top: -0.5em; vertical-align: baseline !important; position: relative;
}

Mises en exposant

Bonjour Patrice
Tu peux voir un exemple sur cette page.
Effectivement, j'ai bien l'impression que la déclaration CSS du Couteau Suisse passe en dernier... D'où ma demande pour savoir à quel endroit placer ma surcharge.

Mises en exposant

Ton lien en exemple ne montre malheureusement pas le problème.
Pour éviter les décalages de ligne, il est aussi possible de configurer les exposants ainsi :

sup, sup.typo_exposants { top: -0.5em; vertical-align: baseline; position: relative; }

Mises en exposant

Bonjour à tous, pour que la surcharge fonctionne, il faut vérifier avec les outils de développement de votre navigateur préféré, que la déclaration CSS est placée après celle du Couteau Suisse.
Il serait aussi possible de créer nativement dans le plugin une variable de configuration afin de régler les valeurs voulues....

Mises en exposant

Bonjour
J'ai le même soucis
A priori, il faudrait modifier le css et plus précisément le paramètre « vertical-align » à 23% par défaut dans le fichier config_outils.php (ligne 1263) :

'code:css' => 'sup, sup.typo_exposants { font-size:78%; font-variant:inherit; line-height:inherit; vertical-align:23%; }'

Il faudrait pouvoir le corriger (le passer à 10% pour moi). Mais je ne sais pas quel fichier je dois créer dans mon répertoire « squelettes » pour surcharger « proprement » le css du plugin...
J'ai créé un fichier /squelettes/css/perso.css dans lequel j'ai intégré la ligne :

sup, sup.typo_exposants { font-size:78%; font-variant:inherit; line-height:inherit; vertical-align:10%; }

mais cela ne fonctionne pas même après avoir vidé le cache bien sûr.
Merci d'avance pour votre aide.

Mises en exposant

Bien vu, merci !

Mises en exposant

... et compléter la liste des balises du texte du présent article :

"Le texte situé entre les balises  et ,  et /code>,  et ,  et , ,  et  ou  et  est protégé : aucune modification d'exposant n'y sera faite."


avec les balises  $et$



Mises en exposant
C'est bien Le Couteau Suisse que j'ai mis à jour.


Mises en exposant
Excellent, est-ce également le cas pour la lame du plugin couteau suisse ?


Mises en exposant
Merci pour les détails François Daniel.
Je viens donc de corriger le code du plugin pour que les exposants laissent désormais tranquilles les balises .


Mises en exposant
Ps : le deuxième math s'écrit évidemment :



Mises en exposant
Il ne s'agit pas d'un plugin mais d'une fonctionnalité opérationnelle en natif dans SPIP depuis la version 1.8. On trouvera des explications ici :
 Insérer des formules mathématiques en LATEX

https://www.spip.net/fr_article3016.html
Pour l'exemple, créez un article contenant le texte suivant :
 $Equation 1 : $$\mathbf{n=\frac{t^{2}N}{t^{2}+(2e)^{2}(N-1)}}$$ Equation 2 : $$n=\frac{1.96^{2}N}{1.96^{2}+(2e)^{2}(N-1)}$$ Equation 3 : $$n=\frac{2.33^{2}N}{2.33^{2}+(2e)^{2}(N-1)}$$$ 
et voyez le résultat avec la lame « Mises en exposant » activée et désactivée.
Cordialement.
FDG


Mises en exposant
Bonjour. De quel plugin s'agit-il exactement ? De quelle façon s'utilise-t-il ?


Mises en exposant
Bonjour,

cette fonctionnalté (Mises en exposant) entre en conflit avec la mise en exposant Latex et en empêche l'expression correcte dans les formules mathématique.
Une fois cette lame désactivée tout rentre dans l'ordre au plan du Latex.
Avez-vous une solution de cohexistence ?
Cordialement
Fdg


Mises en exposant
Bonjour,

La Mises en exposant provoque une très légère augmentation de l'interlignage du paragraphe entre la ligne de texte de l'exposant et celle qui se trouve juste au-dessus.

Comment éviter cet affichage ?
exemple : http://keraluc.com/Quimper-un-centre-faiencier

sur la 3^e ligne du paragraphe


Mises en exposant
Bonjour,
Est-il prévu de porter ce plugin en SPIP 3 ? Je veux dire : le plugin seul, hors du couteau suisse.
Cette fonctionnalité est diablement utile, à mon sens elle mérite de pouvoir être installée sans passer par le couteau, qui est parfois inutilement lourd pour les projets les plus simples.
Merci !


Mises en exposant
Précision oubliée : je suis sous Spip 2.1.10 [17657].

Et Couteau suisse 1.8.43.03 [50953] bien sûr.
La gagnante de mes seconds tests est… aucune lame.
Récapitulons :

— soit que je désactive tous les plugins sauf le Couteau suisse,

— soit que je désactive toutes les lames du Couteau suisse, sauf celle « Exposants typographiques »,
mon texte précité ne s'affiche pas (seules les notes s'affichent) si j'ai comme mes_options.php :
'; $data['fr'][2][] = '...'; $data['fr'][3][] = '…'; return $data;
}
?>
(Je suis prêt à donner mes codes, dans ce cas je fais d'abord une sauvegarde complète et tu peux constater et intervenir sans souci.)


Mises en exposant
Je précise :
Pour le test, voici mon mes_options.php :
'; $data['fr'][2][] = '...'; $data['fr'][3][] = '…'; return $data;
}
?>
Je désactive tous les plugins sauf le Couteau suisse (je me retrouve donc avec la “dist” en partie publique).
Dans mon article de test, il y a seulement le texte précité (de mon message précédent ici).
Je vide le cache.
Et ainsi je reproduis très bien mon propre problème…
Il semble qu'il ne me reste plus qu'à désactiver les autres lames du Couteau suisse ;-) que celle « Exposants typographiques ».


Mises en exposant
Salut, je viens de reproduire ton exemple ci-dessus, et tout est totalement OK chez moi... Tu es sous quel SPIP ? Au hasard, as-tu bien mis les «  » et « ?> » dans mes_options.php ?



Mises en exposant
Salut,
Désolé pour l'interruption de mon travail sur la page :

http://www.spip-contrib.net/3858?var_mode=preview

je vais reprendre pour pouvoir la publier.
Ici je rapporte un « test » involontaire, après une mise à jour de Spip (dernière version) sur un site (mon propre site personnel, que j'avais trop longtemps laissé tomber !) et donc des plugins, donc du Couteau suisse (dernière version…).
Soit le texte saisi :
{{{Psykhế / Ψυχή}}} Déjà Aristote à l'encontre des pythagoriciens et de Platon avait fait de l'âme une réalité inséparable du corps. Pour lui l'âme et le corps ne sont pas deux substances distinctes mais deux éléments inséparables d'une substance une. L'âme ne peut exister en dehors d'un corps. Aristote définit alors l'âme comme “une entéléchie première d'un corps naturel ayant la vie en puissance, c'est à dire d'un corps organisé” [[Aristote, {De l'âme}, p. 23.]]. Aristote l'énonce dans {De l'âme}. La ψυχή n'est pas séparée du corps : σώματος δἑ τι ; elle est “quelque chose du corps” en interdépendance, “(n')impliquant aucune idée de subordination” [[Aristote, {De l'âme}, p. 79.]]. La ψυχή, comme la pulsion, est un concept-limite. Elle est le proprement vivant, ce qui fait que le vivant est vivant et se “déploie”. C'est donc une notion centrale dans la conception de la vie. {{Difficilement traduisible}}, cette notion rejoint les recherches qui étudient le niveau le plus fondamental de la vie psychique comme faculté de faire émerger des significations. La vie psychique ou l'activité psychique (dans ses aspects conscient et inconscient) est inscrite corporellement dans le corps, comme l'affirme F. Varela, neurobiologiste, directeur de recherche au CNRS. Plus particulièrement Varela étudie la cognition comme propriété émergente des systèmes vivants complexes (le réel biologique). Le βίος, pour reprendre le terme d'A. Pichot, serait le fondement véritable des systèmes représentationnels. Tout cela en relation avec le contexte culturel et symbolique, la relation à l'autre : la ψυχή n'est séparable ni du corps, ni du monde. Mais là n'est pas notre propos. Aristote en avait donc l'intuition. À la ψυχή il associe différentes fonctions (δυνἁμεις) : nutritive (θρεπτκή), sensitive (αἰσθητική), pensante (διανοητική), désirante (ὀρεκτική), motrice (κινετική) etc. Il est à noter qu'Aristote considère la fonction désirante et la fonction motrice comme des effets secondaires de la sensation (inscription de la psyché dans le corps vivant-vécu) dans la mesure où le désir présuppose l'imagination et provoque le mouvement. Stefan Hassen Chedri
Soit la lame du Couteau suisse « Mises en exposants » activée.
Jusque là tout va bien.
Soit la surcharge insérée dans mes_options.php :
 function typo_exposants_installe() { $data = typo_exposants_installe_dist(); $data['fr'][0][] = '/°|&(?:#176|deg);/'; $data['fr'][1][] = _TYPO_class.'o'; $data['fr'][2][] = '...'; $data['fr'][3][] = '…'; return $data;
}
Alors là tout fout l'camp…
Plus aucun texte ne s'affiche, tant en partie privée qu'en partie publique (non seulement le texte précité, mais toute autre partie de texte au dessus).
Cependant, les notes de bas de page s'affichent…
C'est incompréhensible pour moi, je ne vois rien de “spécial” ;-) dans ce texte…
 ? Merci pour un examen du problème.


Mises en exposant
Merci pour le nouvel article. En ce qui concerne le traitement sur les titres, je viens d'essayer ça marche bien. Il y a peut-être un plugin qui vient en interférence inhiber ce traitement. Tu peux chercher dans quelque part une ligne qui ressemble à :
$GLOBALS['table_des_traitements']['TITRE'][]='truc(%s)';
Voici la ligne du CS concernant la surcharge ci-dessus :
$GLOBALS['table_des_traitements']['TITRE'][]='typo(insertions_pre_propre(%s),"TYPO",$connect)';


Mises en exposant
Merci.

Ok j'ai fait une ébauche d'article pour que tout le monde puisse en profiter :

http://www.spip-contrib.net/3858?var_mode=preview.
Pour l'instant de ton message qui précède je n'ai mis en œuvre (“testé”) que :
function insertions_surcharger_outil($tab) { $tab[' traitement:TITRE:pre_typo, traitement:TITRE/mots:pre_typo, traitement:DESCRIPTIF '] = 'insertions_pre_propre'; return $tab; }
Ceci apporte bien le traitement de la « Description » des images, documents insérés dans les articles, mais pas de leur « Titre ». Cf. ici. Et pas de la page backend (mais est-ce possible ?).


Mises en exposant
Il me semble que les balises concernées sont : #TITRE et #DESCRIPTIF
Ne voudrais-tu pas créer un article ici-même avec tous ces exemples de surcharge ? ça serait bien de réunir ce travail et d'en faire profiter tout le monde, non ?
Voici un exemple de code de surcharge :
function insertions_installe() { $data = insertions_installe_dist(); // str_replace() dans $data[0][0] $data[0][0][0][] = 'insertions'; $data[0][0][1][] = 'INSERTIONS'; // preg_replace() dans $data[0][1] $data[0][1][0][] = '/\\ba *capella\\b/'; $data[0][1][1][] = 'a capella'; return $data; } function insertions_surcharger_outil($tab) { $tab['traitement:TITRE:pre_typo, traitement:TITRE/mots:pre_typo, traitement:DESCRIPTIF'] = 'insertions_pre_propre'; return $tab; }
Je me demande finalement si c'est pas mieux de redéfinir la variable par défaut. A l'inverse du code précédent, l'utilisateur « voit » dans son cadre ces nouvelles corrections et peut même les retirer. Ici on n'initialise que la valeur par défaut (donc si elle n'a jamais été validée auparavant, donc absente de la base de donnée) de la variable insertions utilisée par l'outil insertions. La manipulation du code PHP est ici un peu plus complexe (attention, Couteau Suisse version >= 1.8.41.00 !) :
// Initialiser les corrections automatiques (CS>=1.8.41.00)
// Nom de la variable : insertions
// Résultat de la fonction : code PHP
function initialiser_variable_insertions($defaut) { eval('$test='.$defaut.';'); $test = "insertions = INSERTIONS
/\ba *capella\b/ = a capella
$test"; return var_export($test,1);
}
Doc : [dev] Le Couteau Suisse à piloter.


Mises en exposant
Salut,
Au sujet connexe des « Corrections automatiques » :
— Comment étendre les Corrections automatiques aux titre et description des images/documents insérés dans les articles ?

Voir ici pour illustration.
— Dans la page backend, les « guillemets droits des informaticiens » (anciennement dits « [faux] guillemets dactylographiques », horreur typographique des « machines à écrire ») :

"."

sont dûment remplacés en français par des « guillemets chevrons doubles » :

«.»

par la lame « Guillemets typographiques ».

Mais les Corrections automatiques du CS ne fonctionnent pas dans cette même page backend.

Y a-t-il une solution possible pour obtenir ces remplacements par la lame Corrections automatiques dans la page backend ? Voir.


Mises en exposant
Problème title dans Sarka-Spip :

Éric, concepteur de Sarka-Spip, a livré la solution ici :

Sarka-SPIP 3 (forum)

(et voir ma réponse après test et les messages suivants).


Mises en exposant
Problème title dans Sarka-Spip :
Voila j'ai répercuté les efforts et diagnostic ci-dessus sur les forums de Sarka-Spip, 

ici (et ici) 

et là.


Mises en exposant
Je viens de vérifier, effectivement la « dist » de Spip ne pose pas de problème sur les titres en partie publique, le code html de mise en exposant est éliminé et le titre d'article s'affiche correctement en texte brut en barre de titre de navigateur.
Désolé pour le temps que je t'ai fait passer sur cette question, au moins je vais pouvoir indiquer cette discussion et ta conclusion sur les forums de Sarka-Spip.
Merci.


Mises en exposant
Ce serait peut-être intéressant de voir dans le code de la fonction textebrut ce qui induit le renvoi d'une chaine nulle dès qu'un caractère non conforme est trouvé...
Je ne pense pas que la dist de SPIP pose un problème sur les titres en public, à l'instar de la partie privée. La mise en variable d'environnement par sarkaspip du title est la source du problème à mon avis.


Mises en exposant
Merci.
J'ai donc placé la ligne
[(#TITRE*|textebrut) - ][(#NOM_SITE_SPIP|textebrut)]

dans inc_header.html

Malheureusement, qu'il y ait ou non un « :» dans le titre d'article, en barre de titre de navigateur seul le nom du site apparaît.
(J'ai aussi essayé ta solution avec |html_entity_decode|textebrut et lorsqu'il n'y a pas de « :» dans le titre, cela marche bien.)
Mais je viens de réaliser que dans l'interface privée, le titre d'article apparaît correctement dans la barre de titre de navigateur, et ce, alors même qu'il y a un « :» et que Spip a inséré une espace insécable dans le titre à l'intérieur de la page avant le « :» (vérifié en regardant le code-source de la page). Donc, qu'est-ce qui est codé pour l'interface privée pour que le titre soit traité et affiché en barre de titre de navigateur comme il se doit en « texte brut » débarrassé des balises html et espaces insécables (ceci vérifié dans le code-source de la page) ? Je voudrais être capable de le trouver…


Mises en exposant
Ah oui, le problème c'est les «  : » où SPIP insère un espace insécable qui plante le couple |html_entity_decode|textebrut !! Plutôt inattendu et rare ...
Bah je te propose tout simplement : (#TITRE*


Mises en exposant
Merci pour ta prompte réponse.
— Après mise à jour du Couteau suisse, les Corrections automatiques fonctionnent effectivement maintenant en Chapeau et Post-scriptum.
Pour ta proposition d'exemple de code en éventuelle surcharge :
L'idée d'exemple de surcharge en mes_options.php me plaît bien : plus facile à manier (lire, vue étendue) et plus sûr car moins de personnes peuvent éventuellement modifier mes_options.php.
J'ai un cas-exemple à proposer sur lequel je tâtonne actuellement.
Je pense qu'avec mon “cas HO” ci-dessous, il y aurait un exemple particulièrement compliqué par rapport à la plupart des autres besoins plus simples, et donc la pédagogie pour d'autres cas serait optimale :-) (par exemple j'ai d'autres abréviations mal formées spécifiques à certains sites, pour obtenir une harmonisation quel que soit ce que tapent les rédacteurs).
J'ai besoin de remplacer « HO » et « H.O » et « HO. » par « H.O. » (et notamment il ne faut pas que je me retrouve avec deux points en fin de phrase si HO se trouve en fin de phrase).
Comme HO peut se retrouver dans des mots en majuscules, il me faut que les remplacements concernent seulement : HO avec espace (ou saut de paragraphe, ou “br,” etc.) ou trait d'union avant, et avec espace ou trait d'union ou ponctuation après (virgule, etc.).
Pour l'instant j'en suis aux premiers tâtonnements en m'inspirant des codages existants dans typo_exposants.php et dans l'interface du Couteau suisse pour la lame Corrections automatiques.
— Pour les titres avec exposant en barre de titre de navigateur :
S'agissant donc du squelette Sarka-Spip, j'ai modifié
squelettes/noisettes/inc_header.html
(en attendant un rectificatif “natif” à Sarka-Spip)
en copiant-collant la ligne que tu indiques (en substitution de la ligne originale).
Le résultat est imprévu : je n'ai plus en barre de titre de navigateur que le nom du site.


Mises en exposant
Et hop : http://zone.spip.org/trac/spip-zone...


Mises en exposant
En ce qui concerne le , on peut voir dans le code de sarkaspip que le titre de la page est calculé comme ceci :</p>
<p>1. Dans article.html :</p>
<div class="precode"><pre class="spip_code spip_code_block language-spip" dir="ltr" style="text-align:left;" data-language="spip"><code><INCLURE{fond=noisettes/inc_header} {meta_titre=#TITRE} {meta_description=#INTRODUCTION{#EVAL{_SARKASPIP_CONFIG_INTRO_META}}}></code></pre></div>
<p>2. Dans noisettes/inc_header.html :</p>
<div class="precode"><pre class="spip_code spip_code_block language-spip" dir="ltr" style="text-align:left;" data-language="spip"><code><title>[(#ENV{meta_titre}|textebrut) - ][(#NOM_SITE_SPIP|textebrut)]
 
Je ne sais pas pour quelle raison (peut-etre la sécurité) le titre est passé en htmlentities() :
	1<sup class="typo_exposants">er</sup> Article pour exemple, problème avec les exposants dans les titres d'articles, voir barre de titre et onglet de navigateur : présence de code html - MAQUETTE DE SITE
 
Il faurait donc coder noisettes/inc_header.html comme ceci :
[(#ENV{meta_titre}|html_entity_decode|textebrut) - ][(#NOM_SITE_SPIP|textebrut)]
 
Comme on peut le voir dans les descriptions des outils évoqués :
 Les Exposants Typographiques  sont remplacés par le pipeline post_typo et concerne donc toutes les balises possédant un traitement automatique |typo ou |propre.
 Les Corrections Automatiques  agissent uniquement par traitement sur la balise #TEXTE. On peut donc :
 Etendre nativement ces corrections à d'autres balises si besoin
 Compléter cet outil par une surcharge perso et adaptée à une utilisation spécifique. Si besoin, je peux fournir un exemple de code.
Je précise que la méthode des traitements est plus performante  car elle cible mieux le contenu à étudier. En gros, un pipeline est appliqué aveuglément sur tous les contenus.


Mises en exposant
Salut.
J'ai deux anomalies (telles à ma vue).
La première, dont je ne sais à quoi elle est due, là est la question : j'utilise le squelette Sarka-Spip.
Lorsque je mets « 1er » ou autre abréviation dans un titre d'article, je me retrouve avec du code html de mise en exposant en barre de titre de navigateur (et en onglet de navigateur). Voir ici. Voir aussi le site de test de Pétarel, qui a bien voulu faire ce test. Sites avec Spip 2.1.10.
J'ai bien vu dans des messages antérieurs du présent forum d'article que le problème s'était posé antérieurement avec le squelette Eva, avec des versions antérieures de Spip.
Quid aujourd'hui s'agissant des nouvelles versions de Spip… ou d'anomalie du squelette Sarka-Spip ? S'agit-il de demander à qui de droit une rectification du squelette Sarka-Spip ? Dans ce cas, que préciser à ce propos ?
La deuxième, que je regroupe ici car la lame « Corrections automatiques » d'objet connexe n'a pas d'article spécifique, est que ces Corrections automatiques fonctionnent dans le champ « Texte » des articles, mais pas dans les champs « Chapeau » et « Post-scriptum », ni dans les messages de partie privée.
Pourtant les Mises en exposants fonctionnent elles en Chapeau et Post-scriptum (y compris dans leurs notes), et aussi en messages de partie privée. Quid de cette différence d'effet ? Cf. la page de test précitée.
Merci pour toute pédagogie…


Mises en exposant
OK. Pour clore ce très long fil, je renvoie les personnes intéressées par le sujet à ce nouvel article : 
— > [dev] Les données du Couteau Suisse.
Comme d'habitude, les retours d'expérience sont les bienvenus.


Mises en exposant
Merci.

S'agissant de « Enluminures typographiques V3 pour SPIP 2 avec PortePlume », j'ai reçu une réponse ici.


Mises en exposant
Les deux outils fonctionnent sur la base d'une recherche de séquences dans un texte, je dirais donc que c'est très similaire. Les performances dépendent du nombre de textes présents sur une page, de leur longueur et de la complexité des séquences, regexpr ou non.
La surcharge a lieu une seule fois au moment de la compilation du CS. Au moment du calcul d'une page donnée et avant sa mise en cache, les tableaux de remplacement sont donc tout prêts (fichier tmp/couteau-suisse/mes_outils.php), ce qui accélère beaucoup les choses. En fonction du réglage de ton cache, la page devient alors statique durant un certain tems (24h par défaut) pendant lequel plus aucun calcul n'est effectué (sauf modifs de contenu évidemment).
A chaque utilisateur la responsabilité de ses surcharges, je n'ai aucun jugement la-dessus !
Quant à l'ellipse, je la vois dans le code en tout cas : http://zone.spip.org/trac/spip-zone...


Mises en exposant
Salut,
Désolé j'avais perdu de vue l'existence de la lame « Corrections automatiques », et pourtant je l'avais activée mais sans y avoir jamais touché : voilà pourquoi je cherchais à utiliser la lame « Exposants typographiques » pour l'ellipse. Merci pour ta pédagogie malgré cela.
J'ai donc inséré dans config/mes_options.php  ceci qui fonctionne effectivement :
function typo_exposants_installe() { $data = typo_exposants_installe_dist(); $data['fr'][0][] = '/°|&(?:#176|deg);/'; $data['fr'][1][] = '^o'; $data['fr'][2][] = '...'; $data['fr'][3][] = '…'; return $data;
}
Ceci dit, quelle est la solution la moins néfaste pour les performances : surcharger ainsi la lame « Exposants typographiques » (en la détournant donc de son but originel tenant à sa dénomination), ou mettre à contribution la lame « Corrections automatiques » ? (Perso par principe j'aime bien les détournements… de cette nature en tout cas !)
Toujours ma page de tests, actuellement avec CS rev. 47629.
(Par ailleurs, je confirme que chez moi le plugin « Enluminures typographiques V3 pour SPIP 2 avec PortePlume » ne s'intéresse en rien aux points de suspension-ellipse, et ne comporte pas de bouton pour insérer … — Donc je reste perplexe sur tes observations à ce propos.)


Mises en exposant
Normal : caractere_charset(46) : ceci est un point tout bête, ce qui signifie en langage RegExp, n'importe quel caractère !
Sinon, peut-être serait-il mieux d'inclure le caractère degré lui-même : '/°|&(?:#176|deg);/'
Dans un cas simple, il serait plus efficace d'abandonner les expressions régulières et revenir à un remplacement simple grâce à str_replace(), ce que fait en partie Enluminures typographiques V3, notamment avec l'ellipse horizontale. Je vais modifier la lame du CS pour qu'elle fasse du str_replace(), notamment sur ^{à remplacer par ^{typo_exposants »>. Dans ce cas, la surcharge suivante, plus simple, devrait fonctionner :}}
function typo_exposants_installe() { $data = typo_exposants_installe_dist(); $data['fr'][2][] = '...'; $data['fr'][3][] = '…'; return $data;
}
Mais je répète que ceci est totalement hors sujet. Pour tout type de remplacement, tu as aussi la lame « Corrections automatiques ».
Attention, pour tes tests, il faut toujours recompiler le CS et vider les caches. Sinon tu risques d'avoir des résultats invalides.


Mises en exposant
3. — Essai de surcharge
Selon l'exemple :
function typo_exposants_installe() { $data = typo_exposants_installe_dist(); $data['fr'][0][] = '/exemple/'; $data['fr'][1][] = 'ex^emple'; return $data;}
dans config/mes_options.php

j'ai placé :
function typo_exposants_installe() { $data = typo_exposants_installe_dist(); $data['fr'][0][] = '/&(?:#176|deg);/'; $data['fr'][1][] = '^o'; return $data;}
Cela fonctionne, merci pour l'exemple.

Mais même fonctionnant, est-ce que mon suivi de l'exemple est “propre”, sans faute ?


Mises en exposant
Merci.
1. — Quoique fautive, l'expression caractere_charset(176|186) n'empêche pas le traitement respectif et cumulatif des deux caractères 176 et 186. Mais donc je retiens comme seule correcte caractere_charset(176).'|'.caractere_charset(186)
 

2. — Il me semblait aussi que dans le passé quelque chose (Spip lui-même ?) remplaçait les trois points accolés pour points de suspension par le caractère 8230. Mais si c'était bien le cas, ce n'est plus le cas. Je n'ai pas trouvé d'extension de Porte-plume qui procure ce remplacement.
C'est pourquoi je compte me servir de la nouvelle possibilité de surcharge pour faire assurer ce traitement par la lame Exposants typographiques. Bien sur je sais que le caractère 8230 n'est pas un exposant. Mais comme on ne met pas les abréviations en exposant (au sens de super), la lame pourrait en théorie être dénommée Abréviations. Et les points de suspension sont une abréviation… mais pas toujours (dénommés “ellipse (horizontale)” en anglais).
Donc, pour essais, dans typo_exposants.php j'ai mis :
$ellipse = caractere_charset(46).'|...|\.\.\.';
avec
"/(?:$ellipse)/", // ellipse : ...
et avec
'…', // ellipse : ...
Mais cela ne marche pas. Cela remplace, notamment dans les articles et ailleurs (mais pas partout) tout par le caractère 8230 (des lignes entières de 8230, et plus rien d'autre dans les articles). Pourtant j'essaye de tout bien transposer le code concernant d'autres remplacements, et j'ai maintenant “échappé” les points dans $ellipse = caractere_charset(46).'|...|\.\.\.';


Mises en exposant
Merci pour les tests.
caractere_charset(186|176) : cette expression est fausse. Elle génère le caractère 186 uniquement puisque l'expression numérique 186|176 = 186. Attention à la syntaxe PHP...
Quant aux trois points, SPIP ne fait-il pas lui-même le remplacement ? Il y a une extension de Porte Plume qui le propose je crois. EN tout cas, on n'est plus dans le sujet des exposants et le point doit être échappé dans 'expression régulière : \.\.\.


Mises en exposant
Ok merci.
caractere_charset(186|176)
fonctionne aussi.
J'ai mis à jour ma page de tests avec un joli tableau pour toutes les abréviations traitées, sauf oubli (au moment de ce message CS 47577 installé).
J'ai aussi essayé de trouver la solution pour remplacer « trois points accolés » par « ellipse » (points de suspension), mais échec de ma part…


Mises en exposant
La lame vient d'être optimisée. La fonction unicode2charset doit être évitée et caractere_charset devrait être bien plus rapide.
unicode2charset('º|°') 
est à remplacer par :
caractere_charset(186).'|'.caractere_charset(176)


Mises en exposant
Oui. Les fonctions d'installation sont à présent surchargeables : http://zone.spip.org/trac/spip-zone...
Petite info au passage :
$ordmasc = unicode2charset('º|°').'|º|º|°|°';
est optimisable ainsi :
$ordmasc = unicode2charset('º|°').'|[78]6;|º|°';
voire :
$ordmasc = unicode2charset('º|°').'|&(?:#1[78]6|ordm|deg);';
(non testé !!)
Différents tests sont les bienvenus qt à ts les exposants transformés...


Mises en exposant
J'ai réussi à appliquer tes observations (en fait je suis un peu vexé de n'avoir pas compris tout seul le rôle de /m, voire \b, s'agissant des m² ! j'ai “transposé” trop littéralement).

Ceci fait, je suis revenu à la seule idée d'ajout de traitement du symbole de degré °.

Voici à nouveau à la même adresse d'article transitoire le nouveau fichier à la modification de traitement ainsi dûment limitée.


Mises en exposant
Salut.

Merci pour les observations, je vais tester.

Bien entendu on va laisser tomber les cubes et ordinaux masculins/féminins, puisque tu m'expliques que cela détériorerait les performances pour rien puisque quasi personne ne s'en sert, c'est sûr, c'est rarissime.

Je vais quand même essayer si j'arrive à appliquer tes indications, et ensuite je proposerai un modificatif seulement pour les symboles de degré.

Cependant comme… je me sers des ordinaux masculins depuis des années pour éviter le symbole de degré (bientôt je ne vais plus avoir besoin de le faire :-) , est-ce qu'il y a une méthode “à ma portée” pour faire une surcharge comme on le fait en Css avec perso.css (et par curiosité) ?


Mises en exposant
Salut.
J'ai bien lu ton message « spam », mais ici c'est mal foutu, je ne peux pas le « déspammer ».
Bref, faut pas oublier que cet outil doit corriger à la volée un texte tapé par un internaute sur son clavier : ça existe les cubes sur un clavier ? Ou les ordinaux maculins/féminins ? A part le degré « ° » qui est en effet sur tous les claviers et employé à tort, il faut aussi tenir compte de la perte de performance ocasionnée par la recherche d'un caractère (dans tous les contenus du site !) qu'on a toutes les chances de ne pas trouver...
- Ceci (« suite de 2 caractères ») :
unicode2charset('º°')
ne fonctionnera pas. Il faut (« un caractère ou un autre ») :
unicode2charset('º|°')
- Ceci :
"/m$ordmasc\b/"
recherche les séquences m° suivies d'un séparateur de mot....
Bienvenue dans le monde des RegExpr !


Mises en exposant
J'ai fait un message avec mes propositions (et échecs) mais il est en cours de “validation” car probablement trop long à cause d'un extrait de code. Autant vaudrait d'ailleurs ne pas le “valider” puisque : cela m'a poussé à faire mieux : un article transitoire pour les tests et le fichier .php modifié en téléchargement.


Mises en exposant
Oui absolument. Cette erreur est passagère et dure le temps d'une recompilation du Couteau Suisse. Merci de le spécifier sur ce forum.


Mises en exposant
Les plus récentes mises à jour du CS (et la dernière à l'heure du présent message : 47504) produisent à l'installation le message suivant répété une vingtaine de fois sur la page :
Warning: preg_replace() [function.preg-replace]: Empty regular expression in /…/plugins/auto/couteau_suisse/outils/typo_exposants.php on line 99
 

Cependant la mise à jour peut être poursuivie sans encombre.


Mises en exposant
Salut. Mon dernier commit devrait résoudre le pb du « m² » (« m² » fonctionnait par contre). Il s'agissait d'un défaut de charset.
Quant au degré tu ne veux toujours pas tester et committer ? ;-)
Les 1° et 2° sont traités actuellement lorsqu'ils sont écrits « 1o » et « 2o »...
Sinon, seules les typos 'fr' et 'en' sont traitées, le russe serait le bienvenu pour les connaisseurs !


Mises en exposant
Je cherche à remplacer le symbole de degré « ° » ainsi que le caractère 186 (« º ») par la lettre « o » en , selon la préconisation des ouvrages de l'Imprimerie nationale relatifs à la typographie.
En effet le symbole de degré est la plupart du temps utilisé faussement dans « 1° », « n° », etc., parce que ce symbole de degré figure au clavier « Azerty » français, tandis que la lettre « o » en  ne serait a priori pas gênante lorsqu'il s'agit réellement de °C (en tout cas pour des sites “littéraires”).
Et le caractère 186 comporte dans certaines polices le soulignement du « petit o », ce qui est contraire à l'usage typographique français, et notamment à la préconisation des ouvrages de l'Imprimerie nationale (mais pratiqué dans d'autres langues, notamment le… russe) (exemple : police courante « Calibri » de Micro$oft).
Pour cela je cherche à procéder par imitation du remplacement du caractère « ² » (comme dans m²). Le hic, c'est que le remplacement du caractère « ² » par ² ne fonctionne pas dans le code actuel de typo_exposants.php.
Que faire ? Je ne sais procéder que par imitation/transposition de code…


Mises en exposant
Oui ce serait bien mais je n'ai pas la disponibilité actuellement pour l'apprentissage de SVN. Donc à la prochaine occasion si tu veux bien toi “committer” cela, y compris en mettant mes initiales « frdm » le cas échéant en commentaire, ce serait plus raisonnable de mon point de vue… désolé de te laisser cet aspect de suite de mes petits travaux que tu trouves judicieux, mais actuellement je ne me vois pas faire plus. Sauf si tu es sur Paris ou proche et si tu voulais me montrer comment on fait… là l'aspect humain pourrait me motiver…


Mises en exposant
Il n'est pas trop tard pour commencer ! Ce 23% t'appartient, c'est toi qui doit le poster ;-)


Mises en exposant
Oui, RealET a “commité” très vite l'amélioration que je soumettais.
Cependant comme je procède par empirisme, tâtonnement et imitation de “structure” de code, j'ai un regret, celui de n'avoir pas proposé d'emblée inherit pour font-variant. Et alors il faut vertical-align: 23%;, et non plus 24%, pour que l'ensemble reste correct y compris en « petites capitales », dans tous les navigateurs mentionnés.
Ce qui donne (dans /squelettes/css/perso.css.html) :
sup, sup.typo_exposants { font-size: 78% !important; font-variant: inherit !important; vertical-align: 23% !important;
}
Le font-size: 78%; est la taille mimimale pour voir le blanc de la boucle des « e » dans Internet Explorer 8 sur mes deux écrans de test sous Windows XP. En dessous de 78% n'est donc pas raisonnable à ma vue.
S'agissant de SVN, je n'ai pas demandé l'autorisation pour pouvoir modifier du code des plugins. En effet, même dans mon champ réduit de préoccupation de “typographie littéraire”, je n'imagine pas “commiter” moi-même, puisque je n'en suis qu'à l'empirisme, tâtonnement, et imitation de “structure” de code… voilà pourquoi je cherche à être hyper-précis dans mes messages, pour favoriser la critique (dans les deux sens !).


Mises en exposant
Je me corrige. Je vois que ta proposition a déjà été postée : http://zone.spip.org/trac/spip-zone......
Suite au prochain numéro !


Mises en exposant
Merci pour ce travail précis.
En gros, tu suggères donc de remplacer « super » par « 24% ». Perso, je ne suis pas contre. Si tu as une amélioration du code, n'hésite pas à user d'SVN pour poster tes corrections sur le plugin.


Mises en exposant
Merci pour cette lame du Couteau suisse qui au vu du forum a demandé beaucoup de recherches des usages typographiques.
Dans /squelettes/css/perso.css.html j'ai placé :
sup { font-size: 78% !important; font-variant: normal !important; vertical-align: 24% !important;
}
sup.typo_exposants { font-size: 78% !important; font-variant: normal !important; vertical-align: 24% !important;
}
pour le résultat harmonisé estimé approprié testé sous Windows XP et avec deux écrans différents, avec respectivement :

— Firefox 4.0.1

— Safari 5.0.5

— Google Chrome 11.0.696.60 beta

— Internet Explorer 8.
Le résultat est légèrement différent dans chaque navigateur, la moyenne est celle estimée appropriée.
Les caractères souhaités ne sont plus en exposant (ce qu'ils ne doivent pas être, sauf pour de véritables exposants mathématiques et autres formules scientifiques), mais en “petits caractères en position haute”. (L'espacement des lignes reste alors constant.)
Par hypothèse, ces réglages conviennent en toute rigueur pour des sites principalement littéraires ; pour autant, ces réglages ne semblent pas présenter d'inconvénient pour des formules scientifiques, et peut-être moins que les mises en exposant scientifique s'agissant de sites littéraires.


Mises en exposant
Rien à voir avec le CS donc. La faute est à EVA qui laisse passer des balises dans les « title ».
Je viens de faire une correction du squelette...


Mises en exposant
Il s'agit de SPIP 1.9.2^e, squelette EVA-Web 3.0, avec le mini-calendrier EVA 1.0, plugin « exposants typographiques » dans le Couteau suisse 1.7.20.03.


Mises en exposant
Salut. Quel SPIP utilises-tu ? Quel mini-calendrier ? Un squelette ? Un plugin ? de quelle version ?
Le #TITRE de l'article est probablement utilisé tel quel alors qu'il devrait passer dans un filtre... Au moins dans : |textebrut|texte_script...


Mises en exposant
Bonjour,
Quand un exposant est mis automatiquement, grâce au plugin, dans le titre d'un article qui référencé dans le « mini-calendrier », cela perturbe l'affichage de l'article au jour donné dans le calendrier. Au lieu d'avoir la date en gras, par ex 22), je me retrouve avec e">22.

Y a-t-il une astuce ou dois-je court-circuiter le plugin pour les titres (en mettant 2è par exemple), pour pouvoir garder cette fonctionnalité très utile pour le corps des articles ?
Merci beaucoup et bravo pour ce travail.


Bug avec le mot « voûtes »
Ah, ta base n'est pas en utf8 ? ou alors tu as mis un mot du genre : vo&ucirc;tes ?


Bug avec le mot « voûtes »
Bonjour,
Le mot « voûtes » devient v(sup class=typos_exposant)o(/sup)ûtes. 
J'ai corrigé le problème avec la balise (html).
La fonction ne devrait-elle pas chercher v^o avec un espace après ?
En tous cas MERCI pour ce travail.


Mises en exposant
... En utilisant les balises de SPIP :  et .


Mises en exposant
Comment écrire la ville de Melle sans qu'elle passe en exposant automatique et sans désactiver cette fonction ?


Mises en exposant
A l'heure actuelle, ne serait-il pas aussi intéressant de prévoir une mise en indice du 2 de CO2 ?


Mises en exposant
Merci beaucoup !


Mises en exposant
Absolument, il s'agissait des accents placés avant « ro ». Ce pb vient d'être corrigé.


Mises en exposant
L'abréviation de « recto » est peut-être utile, mais ça serait bien qu'elle ne s'applique qu'au mot « ro » et non pas à tous les mots finissant par « ro », tels que « zéro », « numéro »...
J'utilise la dernière version stable de SPIP (1.9.2^e) et je viens d'installer le plugin Couteau Suisse.


Mises en exposant
En CSS, j'utilise...
sup.typo_exposants {
font-size:75%;
font-variant:normal;
vertical-align:top !important;
}
... pour obtenir l'effet visible ici. Les impressions d'écran ont été faites sous FF3.

En ce qui concerne les abréviations de mots au pluriel (et non le pluriel des abréviations), je crois qu'on peut les garder.

Oui.

Quant au féminin, je ne suis pas sûr qu'il soit indispensable pour M^gr, même si je ne suis pas très au fait des nouveautés de la religion dans ce domaine...

Là, je pense que c'est même « hérétique » de garder ce type de féminin.
Je préparerai une récapitulation de nos conversations pour corriger l'article et le plugin.


Mises en exposant
À propos des règles CSS, le problème me semble insoluble. J'ai fait une page de tests avec différentes tailles (font-size) et différents alignements verticaux (vertical-align) : http://www.miakinen.net/tmp/lettressup.
Ensuite j'ai demandé à la faire tester par différents navigateurs : http://browsershots.org/http://www.miakinen.net/tmp/lettressup.
Eh bien je n'ai pas l'impression qu'il y ait un seul cas qui, d'un navigateur à l'autre, ne soit pas soit trop grand soit trop petit, soit trop haut soit trop bas, et même soit trop collé (au f) soit trop éloigné (du N) ! Bon, je vais essayer de trouver quand même le « moins pire » dans tout ça et je vous tiens au courant de mes recherches.
En ce qui concerne les abréviations de mots au pluriel (et non le pluriel des abréviations), je crois qu'on peut les garder. Quant au féminin, je ne suis pas sûr qu'il soit indispensable pour M^gr, même si je ne suis pas très au fait des nouveautés de la religion dans ce domaine...


Mises en exposant
60% ? Je viens de faire quelques essais, et la lisibilité est vraiment compromise à cette taille, tu penses pas ? La balise >sup> est fixée à peu près à 80% dans Firefox. En 2008, nous sommes encore sur des écrans agressifs et à basse résolution, où les pixels sont très vixibles ;-)
Que fait-on finalement pour M^e, M^gr, D^r et P^r ? Définitivement, ni pluriel... ni féminin ?
Bon, intéressant l'article québecquois. J'adore ce titre : « Banque de dépannage linguistique ». Vais-je devoir ajouter une option « Activer les raccourcis québecquois » !?


Mises en exposant
Par ailleurs, Patrice, je te suggère de remplacer le 75% par 60% dans la définition CSS :
sup.typo_exposants { font-size:60%; font-variant:normal; vertical-align:super;
}

Cela correspond bien mieux à l'usage habituel pour ces lettres supérieures, qu'il ne faut pas confondre avec des exposants.


Mises en exposant
« Alors que faire de « D^rs » ? »
En France, rien. ;-)

... il a vu M. Machin, rencontré M^e Dutilleul, croisé M^gr Lefébure, rattrapé le docteur Grandin. (« Docteur » n'est pas en France un titre de civilité.)

Sinon, hors de France, on peut suivre l'exemple de l'office québécois de la langue française, qui prévoit D^r et D^rs, mais aussi D^re et D^res :

http://66.46.185.79/bdl/gabarit_bdl.asp?id=2778


Mises en exposant
Alors que faire de « D^rs » ?
D'autre part, Lacroux cite bien (§ 3.3.1) « V^ve » (contrairement à ce que j'affirmais). Je suis toujours à la recherche de « P^r ».


Mises en exposant
Il a raison ! Ce ne sont pas les abréviations qui prennent la marque du pluriel (sauf quelques cas tels que « M. » pouvant devenir « MM. »), mais les mots au pluriel qui peuvent s'abréger. Ainsi, comme il le dit, M^mes n'est pas M^me plus la marque du pluriel, mais l'abréviation de Mesdames. Et de la même manière 2^es n'est pas 2^e plus la marque du pluriel, mais l'abréviation de deuxièmes.


Mises en exposant
Tes arguments se tiennent. Ce qui me gêne juste, c'est que Lacroux, à l'article « Abréviations », § 3.11, dit que « les abréviations, en tant que telles, ne prennent généralement pas la marque du pluriel » et cite quelques exceptions, expliquant que « M^mes » n'est pas la mise au pluriel de l'abréviation mais l'abréviation du pluriel « Mesdames ». Il donne cependant « f^os », qui suit la même logique.
J'ajoute que, finalement, « D^rs » n'est pas absurde.
Bref, je ne suis sûr de rien.


Mises en exposant
C'est vrai qu'il n'y a pas d'exemple explicite chez Lacroux, mais c'est probablement parce que ça lui semblait évident. Il s'agit d'un cas un peu particulier d'abréviation par retranchement médian (particulier parce que le nombre en lettres est remplacé par sa valeur en chiffres), et donc si « deuxième » devient « 2^e », alors « deuxièmes » doit devenir « 2^es ».
« Deuxièmes » ne peut pas donner « 2^e » parce qu'il manque la dernière lettre et qu'il faudrait donc un point abréviatif, mais il ne peut pas donner « 2^e. » non plus car la coupure n'interviendrait alors ni après une consonne ni avant une voyelle, ces deux règles étant impératives.
Noter que http://jacques-andre.fr/faqtypo/lessons.pdf indique bien « 1^res » pour l'abréviation de « premières », même s'il ne donne pas d'autres exemples de pluriel. En revanche, tout ce que je peux trouver sur la toile en cherchant « typographie abréviations deuxièmes » me donne bien « 2^es ».


Mises en exposant
Oups, erreur de ma part : « 2^mes » devrait donner « 2^e » ou « 2^es ». Je ne trouve, ni chez Lacroux ni dans l'IN, aucune référence à une mise au pluriel des ordinaux.


Mises en exposant
Et donc, « 2^es » ne donne ni « 2^mes » ni « 2^me » mais bien « 2^es ». Ça me semble correct, non ?


Mises en exposant
OK. Il existe un fichier de test qui analyse quelque cas : /ecrire/?exec=test_couteau_suisse
Aujourd'hui, « 2^e, 3^e, 4^e, 5^es, 6^es, 7^es » donne : « 2^e, 3^e, 4^e, 5^es, 6^es, 7^es »


Mises en exposant
Je suis en train d'analyser en détail les modifications effectuées et de les comparer aux règles orthotypographiques courantes (dans le cadre d'un dossier en traitement automatisé des langues). Il y a encore d'autres erreurs, que je communiquerai dans quelques temps. Par exemple, « 2^es » (et toute la clique) ne devrait pas donner « 2^mes » mais « 2^me ».


Mises en exposant
OK, je viens de modifier l'article et de supprimer les pluriels : « D^rs », « P^rs », « M^es » et « V^ves ».
A voir donc quoi décider pour les autres raccourcis...


Mises en exposant

Pendant que j'y suis, je pensais ajouter à ce plugin la possibilité d'un raccourci rapide pour les exposants, du genre : « pouce^2 » pour « pouce2 ». Si on étend aux indices ou si on accepte les expressions compliquées, pkoi pas : « pouce[^2] » et « H[2^]O » (ou « H[_2]O » ?) pour « pouce2 » et pour H2O... Au lieu des crochets, peut-être des parenthèses... Qu'en penses-tu (...)

Que c'est une bonne idée.
Le Lexique des règles typos donne bien « É^ts » mais ne mentionne pas « S^té ». Lacroux donne « É^ts » ou « É^ts » et ne parle pas de « S^té ».
J'ajoute que les pluriels « D^rs », « P^rs », « M^es » et « V^ves » ne sont pas acceptés par Lacroux (qui ne cite que « M^lles », « M^mes », « MM. », « RR. PP. », « LL. AA. SS. », « f^os » et « sqq. ») et que « P^r », « V^ve », « M^n » et « M^d » ne sont pas non plus attestés, ni chez Lacroux ni dans le LRTUIN.
Je n'ai pas le temps, actuellement, d'opérer les modifications et de les mettre en ligne sur la zone.


Mises en exposant
Bonjour,

En effet, il faudrait vérifier les autres abréviations. Ce qui personnellement m'a fait réagir, c'est « bd » et « fg » écrits avec la 2^e lettre en lettre supérieure.

Concernant les abréviations par retranchement médian (c'est-à-dire conservant la première et la dernière lettre), Lacroux explique que les lettres supérieures sont nécessaires dans les abréviations qui peuvent être « lues au long » (no pour numéro, r^o pour recto, Me pour maître, etc.). Pour les abréviations qui ne peuvent pas être lues au long, comme les quatre que tu cites, les lettres supérieures sont facultatives mais très recommandées après une majuscule initiale (M^lle) ; en revanche elles sont en principe proscrites s'il n'y a pas de majuscule initiale (bd ou fg).

Je le cite : « b^d ou f^g sont à la fois fautifs, cohérents et séduisants. »

Pour info, pour « boulevard » il donne comme abréviations possibles « bd » et « boul. », et pour « faubourg » il donne « fg » et « faub. ». Bien entendu, l'abréviation dans ce cas n'est jamais nécessaire.


Mises en exposant
OK alors. Ne faudrait-il pas vérifier aussi les autres abréviations comme : É^ts, S^té, bd ou fg ?
Je te laisse déposer ses corrections sur la zone ?
Pendant que j'y suis, je pensais ajouter à ce plugin la possibilité d'un raccourci rapide pour les exposants, du genre : « pouce^2 » pour « pouce² ».
Si on étend aux indices ou si on accepte les expressions compliquées, pkoi pas : « pouce[^2] » et « H[2^]O » (ou « H[_2]O » ?) pour « pouce² » et pour H₂O...
Au lieu des crochets, peut-être des parenthèses...
Qu'en penses-tu ?


Mises en exposant
Bonjour,
Le plugin s'occupe mal de saint et sainte. En effet, d'après l'Imprimerie française (Lexique des règles typographiques en usage à l'Imprimerie nationale) et Lacroux (Orthotypographie), ces deux mots ne peuvent être abrégés que dans le cas de noms propres (et, précise l'IN, qu'exceptionnellement ; pour Lacroux, toute abréviation est proscrite, sauf pour les toponymes en cas de manque de place — sur une carte ou un calendrier par exemple). Du reste, la forme abrégée — qui reste donc rarissime — se fait sans mise en exposant (St, Sts, Ste et Stes).
Lacroux cite les formes « St-Étienne » ou « St-Simon » comme des « fautes graves » ou des « graphies monstrueuses ».
Il faudrait donc désactiver ces modifications.


petit problème avec 2^e
Il faut que tu utilises la balise  pour tes exemples, là c'est pas compréhensible...
En tout cas, ta syntaxe :  est dangeureuse car #TITRE passe par les fonctions de typographie et peut contenir des exposants. De plus une présence de guillemets mettrait ton code en défaut.

Mets plutot : #TITRE* ou [(#TITRE|textebrut|attribut_html)]...
C'est peut-être ça l'erreur à toi de vérifier..


petit problème avec 2^e
Petit retour avec la dernière version du plugin :
le code source de ma boucle :
[code]
 (#TITRE
[/code]
donne :
[code]
e tour « > Election municipale - Résultats du 2^e tour 
[/code]
Ce qui donne à l'écran :
e tour »> Election municipale - Résultats du 2^e tour
Lorsque je désactive la lame exposant typographique l'affichage est plus compréhensible :
Election municipale - Résultats du 2^e tour
... même si l'abréviation n'est pas correcte.
à part ça le couteau suisse c'est génial ! je m'en vais tester de ce pas les jolis coins..