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

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