Mises en exposant

... ou correction typographique des abréviations courantes

Cet outil du Couteau Suisse améliore le rendu typographique des abréviations courantes, en mettant en exposant les éléments nécessaires (ainsi, Mme devient Mme) et en corrigeant les erreurs courantes (2ème ou 2me, par exemple, deviennent 2e, seule abréviation correcte).

Présentation

Cet outil est une fonctionnalité du plugin Le Couteau Suisse que vous pouvez trouver ici : Le Couteau Suisse. Pour avoir accès aux corrections typographiques des exposants, il vous faut donc avoir préalablement installé ce plugin.

Ensuite, une fois l’outil Mises en exposant activé sur la page d’administration du plugin en espace privé, vous avez donc la possibilité d’améliorer automatiquement le rendu typographique des abréviations courantes, en mettant en exposant les éléments nécessaires. Il se base sur les remplacements par expressions régulières précédemment publiés ici par Raphaël Meyssen.

Facile à activer ou désactiver, son utilisation est transparente pour les éditeurs. L’outil se sert du pipeline (ou « point d’entrée ») : post_typo.

Abréviations concernées

Dans l’état actuel, ce plugin remplace (singuliers et pluriels) :
-  Melle ou Mlle par : Mlle ;
-  Mme par : Mme ;
-  1ier, 1ière, 1ère ou Iier, Iière, Ière par : 1er (masculin) et 1re (féminin) ou Ier et Ire (chiffres romains) ;
-  2ième, 2ème, 2me ou IIième, IIème, IIme (fonctionne aussi avec les autres chiffres) par : 2e et IIe (seules formes correctes) ; 2nd par : 2nd.

Dans certaines conditions précises (abréviations suivies d’un espace, d’un point ou d’un tiret simple), sont également remplacés :
-  Dr et Pr par : Dr et Pr (au singulier uniquement)

Ici seront remplacées les expressions suivantes si elle sont suivies par un espace puis une majuscule :
-  Me par : Me (Maître, au singulier uniquement)

D’autres expressions (au singulier et parfois au pluriel) sont encore remplacées :
-  , m2, m3 par : m2 et m3 ;
-  Mgr par : Mgr (Monseigneur, au singulier uniquement)
-  Mn(s) et Md(s) par : Mn(s) et Md(s)
(Million(s), Milliard(s))
-  Vve par : Vve (Veuve, au singulier uniquement)

-  Cie(s), Sté(s) et Ets par : Cie(s), Sté(s) et Éts (Compagnie(s), Société(s), Établissements)
-  ro, vo 1o, 2o, etc. par : ro (recto), vo (verso), 1o (primo), 2o (secundo), etc.

Les éventuelles formes plurielles sont traitées (soit intégrées dans le cas de MmesMmes, soit annulées dans le cas de 2es — et autres variantes erronées — qui reste 2e) et les abréviations obtenues sont conformes à celles indiquées dans l’article « Abréviations » du Lexique des règles typographiques en usage à l’Imprimerie nationale (presses de l’Imprimerie nationale, Paris, 2002).

Le cas de Monsieur, que l’on devrait, d’après l’Imprimerie nationale, abréger en M. et non Mr ou Mr, n’est pas pris en charge par un remplacement de Mr en M., afin que l’on puisse écrire l’abréviation de Mister, soit Mr (usage anglais) ou Mr. (usage américain), sans mise en exposant (de même que Mrs ou Mrs.).

Pour les utilisateurs moins scrupuleux des règles, le plugin permet d’outrepasser les recommandations officielles en activant l’option de configuration dédiée, permettant de mettre en exposant les raccourcis suivants :
-  Bd par : Bd (Boulevard), Fg par : Fg (Faubourg)
-  St(e)(s), Bx et Bse(s) par : St(e)(s), Bx et Bse(s) (abréviations suivies d’un espace, d’un point ou d’un tiret simple)

Technique

Le remplacement de 1ers se traduit par le code HTML suivant :

   1<sup class="typo_exposants">ers</sup>

Afin de lever toute ambiguïté, la balise <sup> (de classe "typo_exposants" ou non) est stylée comme ceci dans le fichier « config_outils.php » :

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

Ceci dit, d’autres styles sont possibles, comme :

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

Ce code suit les travaux et observations de frdm développés dans le forum ci-dessous.

Notes :

-  Cette fonctionnalité sur les exposants ne fonctionne pour l’instant que sur les textes français, mais d’autres langues peuvent être intégrées facilement dans le fichier outils/typo_exposants.php.
-  Les textes anglais bénéficient d’une mise en exposant des nombres ordinaux : 1st, 2nd, 3rd, 4th, etc.
-  Le texte situé entre les balises <html> et </html>, <code> et </code>, <cadre> et </cadre>, <frame> et </frame>, <script> et </script>, <acronym> et </acronym>, <cite> et </cite> ou <math> et </math> est protégé : aucune modification d’exposant n’y sera faite.
-  De la même façon, toutes les balises HTML contenant elles-même des guillemets (comme : <div id="mon_id">) sont bien sûr protégées afin d’éviter tout remplacement intempestif du code.
-  Cas des RSS. Pour éviter que les flux RSS ne recoivent des textes du genre "3<sup class="typo_exposants">e</sup> tour", le filtre supprimer_tags pourra vous aider. Voici un exemple de code à utiliser dans vos squelettes backend :
[(#TITRE|supprimer_tags|supprimer_numero|texte_backend)]. Ici, "2ème« sera bien remplacé par »2e", mais sans balise HTML.

Pour les spécialistes :

-  Le pipeline utilisé est : post_typo
-  Le fichier inclus est : outils/typo_exposants.php

Améliorations possibles
D’autres remplacements sont faciles à mettre en place : il faut pour cela connaître les expressions régulières et les ajouter au fichier outils/typo_exposants.php.

Il serait possible un paramétrage sur l’interface de gestion privée permettant de choisir quels remplacements activer ou non.

Débat

Suite à une conversation de forum avec Jean-Christophe, je retranscris ici quelques remarques.

Un petit rappel : Le Couteau Suisse met à votre disposition une page de test accessible en partie privée grâce à l’url : ecrire/?exec=test_couteau_suisse

Les chiffres romains

Les petits chiffres romains (I, V & X) sont pris en compte, mais le cas de « Ire » ou « Ires » a été volontairement laissé pour cause de performance (les regexpr risquent de gonfler) et de confusion avec « Irez-vous » par exemple. Les chiffres romains s’emploient-ils si souvent au féminin ?

Quant aux 50, 100, 500 & 1000 (L, C, D & M), c’est un peu pareil. comment distinguer l’article « Le » de 50e : « Le » ? Je me disais que les chiffres romains s’emploient le plus souvent pour les siècles et qu’on était tranquille au moins jusque 21...

Ici doit-on choisir quelles sont les limites d’usage afin de ne pas grever les performances pour quelques cas particuliers, inusités la plupart du temps. Je veux bien ouvrir le débat.

Les abréviations, dans cet article, sont mises en italique parce qu’elles sont citées (cas d’autonymie). Il va de soi que le plugin ne les met pas en italique dans le corps du texte.

Le logo a été créé sous GIMP au moyen d’une image publiée sous licence GFDL par Matthias Kabel pour Wikimedia Commons. Consulter cette page pour plus de détails.

Discussion

27 discussions

  • 5

    Bonjour,
    Cas de « km2 » qui ne semble pas traité.. (alors que « m2 » 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

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

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

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

    • 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.

    • 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<sup>2</sup>

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

    • 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

    Répondre à ce message

  • 8

    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 3e ligne du paragraphe

    • 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.

    • 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....

    • 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;    
      }
    • 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.

    • 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;
      }
    • 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...

    • 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.

    • 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.

    Répondre à ce message

  • 8

    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

    Répondre à ce message

  • 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 !

    Répondre à ce message

  • 3

    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</sup>';
    		$data['fr'][2][] = '...';
    		$data['fr'][3][] = '&hellip;';
    		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.

    • 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 « <?php » et « ?> » dans mes_options.php ?

    • Je précise :

      Pour le test, voici mon mes_options.php :

      <?php
       function typo_exposants_installe() {
      		$data = typo_exposants_installe_dist();
      		$data['fr'][0][] = '/°|&(?:#176|deg);/';
      		$data['fr'][1][] = _TYPO_class.'o</sup>';
      		$data['fr'][2][] = '...';
      		$data['fr'][3][] = '&hellip;';
      		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 ».

    • 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 :

      <?php
      function typo_exposants_installe() {
                      $data = typo_exposants_installe_dist();
                      $data['fr'][0][] = '/°|&(?:#176|deg);/';
                      $data['fr'][1][] = _TYPO_class.'o</sup>';
                      $data['fr'][2][] = '...';
                      $data['fr'][3][] = '&hellip;';
                      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.)

    Répondre à ce message

  • 3

    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.

    • 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][] = '<i>a capella</i>';
      	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/ = <i>a capella</i>
      $test";
          return var_export($test,1);
      }

      Doc : [dev] Le Couteau Suisse à piloter.

    • 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 ?).

    • 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)';

    Répondre à ce message

  • 9

    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…

    • En ce qui concerne le <title>, on peut voir dans le code de sarkaspip que le titre de la page est calculé comme ceci :

      1. Dans article.html :

      <INCLURE{fond=noisettes/inc_header}
      		{meta_titre=#TITRE}
      		{meta_description=#INTRODUCTION{#EVAL{_SARKASPIP_CONFIG_INTRO_META}}}>

      2. Dans noisettes/inc_header.html :

      <title>[(#ENV{meta_titre}|textebrut) - ][(#NOM_SITE_SPIP|textebrut)]</title>

       

      Je ne sais pas pour quelle raison (peut-etre la sécurité) le titre est passé en htmlentities() :

      	<title>1&lt;sup class=&quot;typo_exposants&quot;&gt;er&lt;/sup&gt; 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</title>

       

      Il faurait donc coder noisettes/inc_header.html comme ceci :

      <title>[(#ENV{meta_titre}|html_entity_decode|textebrut) - ][(#NOM_SITE_SPIP|textebrut)]</title>

       

      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.

    • 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.

    • 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*

    • Merci.

      J’ai donc placé la ligne

      <title>[(#TITRE*|textebrut) - ][(#NOM_SITE_SPIP|textebrut)]</title>


      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…

    • 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.

    • 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.

    • 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 .

    • 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).

    Répondre à ce message

  • 16

    Je cherche à remplacer le symbole de degré « ° » ainsi que le caractère 186 (« º ») par la lettre « o » en <sup class="typo_exposants">, 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 «  », «  », etc., parce que ce symbole de degré figure au clavier « Azerty » français, tandis que la lettre « o » en <sup class="typo_exposants"> 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 ). Le hic, c’est que le remplacement du caractère « ² » par <sup class="typo_exposants">2</sup> ne fonctionne pas dans le code actuel de typo_exposants.php.
    Que faire ? Je ne sais procéder que par imitation/transposition de code…

    • Salut. Mon dernier commit devrait résoudre le pb du «  » (« m2 » 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 !

    • 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.

    • 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('&#186;&#176;')
      ne fonctionnera pas. Il faut (« un caractère ou un autre ») :
      unicode2charset('&#186;|&#176;')

      -  Ceci :
      "/m$ordmasc\b/"
      recherche les séquences m° suivies d’un séparateur de mot....

      Bienvenue dans le monde des RegExpr !

    • 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é) ?

    • 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 m2 ! 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.

    • Oui. Les fonctions d’installation sont à présent surchargeables : http://zone.spip.org/trac/spip-zone...

      Petite info au passage :
      $ordmasc = unicode2charset('&#186;|&#176;').'|&#186;|&ordm;|&#176;|&deg;';
      est optimisable ainsi :
      $ordmasc = unicode2charset('&#186;|&#176;').'|&#1[78]6;|&ordm;|&deg;';
      voire :
      $ordmasc = unicode2charset('&#186;|&#176;').'|&(?:#1[78]6|ordm|deg);';
      (non testé !!)

      Différents tests sont les bienvenus qt à ts les exposants transformés...

    • La lame vient d’être optimisée. La fonction unicode2charset doit être évitée et caractere_charset devrait être bien plus rapide.

      unicode2charset('&#186;|&#176;')
      est à remplacer par :
      caractere_charset(186).'|'.caractere_charset(176)

    • 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…

    • 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 : \.\.\.

    • 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).'|&#46;&#46;&#46;|\.\.\.';

      avec

      "/(?:$ellipse)/", // ellipse : ...

      et avec

      '&#8230;', // 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).'|&#46;&#46;&#46;|\.\.\.';

    • 3. — Essai de surcharge

      Selon l’exemple :

      function typo_exposants_installe() {
      	$data = typo_exposants_installe_dist();
      	$data['fr'][0][] = '/exemple/';
      	$data['fr'][1][] = 'ex<sup>emple</sup>';
      	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][] = '<sup class="typo_exposants">o</sup>';
      	return $data;}

      Cela fonctionne, merci pour l’exemple.
      Mais même fonctionnant, est-ce que mon suivi de l’exemple est “propre”, sans faute ?

    • 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 <sup> à remplacer par <sup class=« 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][] = '&hellip;';
               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.

    • 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][] = '<sup class="typo_exposants">o</sup>';
      	$data['fr'][2][] = '...';
      	$data['fr'][3][] = '&hellip;';
      	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 &hellip; — Donc je reste perplexe sur tes observations à ce propos.)

    • 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...

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

    • 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.

    Répondre à ce message

  • 1

    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.

    • 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.

    Répondre à ce message

  • 5

    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.

    • 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.

    • 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 !

    • 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 !).

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

    • 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…

    Répondre à ce message

  • 3
    mat bernier

    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.

    • 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...

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

    • 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...

    Répondre à ce message

  • 1

    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 vo avec un espace après ?

    En tous cas MERCI pour ce travail.

    • Ah, ta base n’est pas en utf8 ? ou alors tu as mis un mot du genre : vo&ucirc;tes ?

    Répondre à ce message

  • 1

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

    • ... En utilisant les balises de SPIP : <html> et </html>.

    Répondre à ce message

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

    Répondre à ce message

  • 2

    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.2e) et je viens d’installer le plugin Couteau Suisse.

    Répondre à ce message

  • 1

    À 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...

    • 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.

    Répondre à ce message

  • 1

    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.

    • 60% ? Je viens de faire quelques essais, et la lisibilité est vraiment compromise à cette taille, tu penses pas ? La balise &gtsup> 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 » !?

    Répondre à ce message

  • « Alors que faire de « Drs » ? »

    En France, rien. ;-)

    <cit. Lacroux, Abréviation, § 2.1.>
    ... il a vu M. Machin, rencontré Me Dutilleul, croisé Mgr Lefébure, rattrapé le docteur Grandin. (« Docteur » n’est pas en France un titre de civilité.)
    </cit.>

    Sinon, hors de France, on peut suivre l’exemple de l’office québécois de la langue française, qui prévoit Dr et Drs, mais aussi Dre et Dres :
    http://66.46.185.79/bdl/gabarit_bdl.asp?id=2778

    Répondre à ce message

  • 1

    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.

    • 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 ».

    Répondre à ce message

  • 1

    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 ».

    • 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.

    Répondre à ce message

  • 1

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

    • 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.

    Répondre à ce message

  • 6

    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.

    • OK alors. Ne faudrait-il pas vérifier aussi les autres abréviations comme : Éts, S, 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 « 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 ?

    • Olivier Miakinen

      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 2e 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, ro 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 (Mlle) ; en revanche elles sont en principe proscrites s’il n’y a pas de majuscule initiale (bd ou fg).

      Je le cite : « bd ou fg 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.

    • 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 ». Lacroux donne « Éts » ou « Éts » et ne parle pas de « S ».

      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.

    • 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...

    • 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, « 2es » (et toute la clique) ne devrait pas donner « 2^mes » mais « 2^me ».

    • OK. Il existe un fichier de test qui analyse quelque cas : /ecrire/?exec=test_couteau_suisse

      Aujourd’hui, « 2e, 3e, 4e, 5es, 6es, 7es » donne : « 2^e, 3^e, 4^e, 5^es, 6^es, 7^es »

    Répondre à ce message

  • 1

    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 2e tour

    [/code]

    Ce qui donne à l’écran :

    e tour »> Election municipale - Résultats du 2e tour

    Lorsque je désactive la lame exposant typographique l’affichage est plus compréhensible :

    Election municipale - Résultats du 2e 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..

    • Il faut que tu utilises la balise <code></code> pour tes exemples, là c’est pas compréhensible...

      En tout cas, ta syntaxe : <a title="#TITRE"> 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..

    Répondre à ce message

  • 3
    Eric Luyckx

    oui oui, j’ai bien lu en FR uniquement
    bon mais j’ai un site bilingue donc je cherche à modifier le code pour
    -  soit utiliser uniquement les fonctions multilingues m2, m3 (au passage j’ai ajouté une class sub pour CO2 NH4 etc)
    -  soit dupliquer texte_exposants_fr en texte_exposants_nl, y supprimer les corrections inutiles

    j’essaie la 2e possibilité en ajoutant

    case 'nl':
    $texte = cs_echappe_balises('html|code|cadre|frame|script|acronym|cite', 'typo_exposants_nl', $texte);

    avant le break mais ça ne fonctionne toujours qu’en FR

    y-a-t’il d’autres scripts à modifier ?

    merci d’avance

    tiens je vois que spip-contrib n’utilise pas la fonction ;-)

    • Eric Luyckx

      oups

      j’ai même été présomptueux, ça marche pour CO2 mais pas pour NH4 ( qui devient CO2)

      là ça me dépasse, je crois que je vais trouver une solution css plus basique

    • Pour les formules chimiques, oui, c’est très intéressant de creuser l’idée et de penser à une intégration au Couteau Suisse. Pourrais-tu faire une liste de tous ces éléments, ou donner une page qui les recence ?

      Pour le code php, c’est simple, il suffit de les ajouter (un par un dans un premier temps) dans le tableau $trouve sous la forme '/\b(NH)(4)\b/', '/\b(CO)(2)\b/', puis de compléter $remplace avec : _TYPO_Dsup, _TYPO_Dsup

      En ce qui concerne la langue, je ne sais pas exactement ce que fait SPIP, il faudrait gratter son code... Ce que je vois là, c’est qu’il semble que typo_exposants prends la langue de l’objet s’il la trouve, sinon la langue du site...

    • A titre d’info, la langue anglaise vient d’être mise en place (pour 1st, 2d, 3rd, etc.). Si ça t’ouvre des pistes...

    Répondre à ce message

  • 1

    Merci pour ce service de correction typographique bien utile, cependant cet affichage d’exposant augmente la hauteur de ligne même si elle est précisée dans la feuille de style en em. Un décalage apparaît donc entre les lignes avec exposant et celle sans.

    Répondre à ce message

  • 12
    J Christophe

    Bonjour

    plugin très intéressant pour corriger quelques fautes typographiques de mes rédacteurs ou de moi-même ;-)

    Mais ça ne marche pas pour 1re ou 2e ?

    Comme il s’agit d’un site de collège, c’est le genre d’erreurs qui risque d’arriver assez fréquemment.

    (Je teste en 1.9.2)

    • normalement, si... tu as un lien public ? dans quel charset est réalisé ton site ?

    • J Christophe

      Je suis encore en phase de tests donc pas en ligne.

      Le site est en utf-8

    • Les autres corrections fonctionnent-elles ? le texte est-il tapé au clavier ? ou copié/collé ? Le squelette est-il celui de SPIP ?

    • J Christophe

      Les autres corrections que j’ai testé oui (Mme Mmes Mlle m2 m3 1er) mais pas 2e ou 1re

      J’ai tapé au clavier en passant par « crayons » ou en passant par l’interface SPIP.

      Et le squelette est un squelette perso basé sur une ancienne version de DURZY mais complètement recodé (j’ai juste gardé l’aspect graphique) visible sous spip 1.9.1 ici

    • Il y a sans doute un pb avec les accents. en tapant l’url ecrire/?exec=test_couteau_suisse, remarques-tu des anomalies, notamment au paragraphe 9 ?

    • Je viens de procéder à quelques aménagements du code. La version 1.7.17.00 du plugin règle-t-elle le problème ?

    • J Christophe

      Je viens de regarder la page test du couteau suisse et oui j’ai quelques erreurs mais peu : STe, XLe L�me LIe, ainsi que le deuxième test sur le lien

      Mais le reste fonctionne ; étonnant d’ailleurs que 3e, 4e soient corrigés alors que Lème donne L�me ?

      Bon je teste la toute dernière version.

    • J Christophe

      C’est nettement mieux avec cette dernière mouture. J’ai encore Ire et Dr(s) ou Pr(s) qui ne sont pas corrigés.

      Dans la page test du couteau, j’ai les mêmes erreurs qu’avant sauf que l’encodage smble différent Lème est devenu Lème, en revanche le ? est redevenu è, autrement dit Lème est corrigé par Lème

    • L’affichage des $texte[xx] comportait un bug d’affichage : le test sur ’Lème’ correspond bien à ’Lème’. Je viens de mettre à jour le plugin, tout en explicitant mieux les exemples.

      Je ne vois aucun pb avec les Dr(s) ou Pr(s) chez moi...

      Le cas de Ire ou Ires a été volontairement laissé pour cause de performance (les regexpr risquent de gonfler) et de risque avec ’Irez-vous’ par exemple. Les chiffres romains s’emploient-ils si souvent au féminin ?

      Quant au 50 (L), c’est pareil. comment distinguer l’article ’Le’ de 50e : ’Le’ ? Je me disais que les chiffres romains s’emploient le plus souvent pour les siècles, non ?

      Ici doit-on choisir quelles sont les limites d’usage afin de ne pas grever les performances pour quelques cas particuliers, inusités la plupart du temps. Je veux bien ouvrir le débat.

    • J Christophe

      Tout à fait d’accord avec toi mais je m’appuyais sur les exemples de la page de test.

      En ce qui me concerne, les corrections qui fonctionnent suffisent amplement à mon bonheur.

      Merci pour ce plugin et merci d’avoir solutionné mon petit problème.

    • J Christophe

      Comme j’avais d’autres soucis, j’ai tout réinstallé bien propre et ... tout fonctionne.

      Juste une dernière remarque 3e (pas d’accent) n’est pas pris en compte.

      Une raison ?

    • non pas de raison a priori. je viens de mettre à jour les regexpr, merci.

    Répondre à ce message

  • 4
    Thibault

    Ce module (j’utilise en fait la dernière version du couteau suisse) modifie malheureusement l’attribut « title= » de mes balises A qui reprennent les chapeaux de mes articles, ce qui a pour effet de casser le code pour la plupart des mises en pages.

    • Bonjour et merci pour ce retour d’expérience. Effectivement, l’intérieur des balises <a> n’étaient pas protégé. C’est maintenant chose faite (uniquement pour les balises en minuscules, par convention HTML) dans la version 1.7.2.13 du plugin.

    • J’ai installé la Version : 1.7.7.05 | stable et je rencontre deux problèmes avec la mise en exposant, à chaque fois l’affichage est « explosé » :

      1) dans un lien de type <a href="mailto:#DESCRIPTIF"> avec une balise #DESCRIPTIF qui dans un article contient un email du type 2e-XXX.

      2) le titre de la rubrique, qui est aussi titre de la page, contient lui-même un caractère du type 1er

      Que faire (sauf à virer l’option exposant du couteau suisse qui par ailleurs me donne satisfaction) ? Merci d’avance.

    • 1. Ton utilisation très spécifique de la balise #DESCRIPTIF peut être résolu en utilisant la balise étoilée : #DESCRIPTIF* , donc non concernée par les traitements.

      2. Quel est ton code HTML ? peut-être ce n’est qu’une question de CSS. Un lien à montrer ?

    • La balise étoilée résout parfaitement le problème. Un grand merci !

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom