Chemin principal : Accueil > LaTeX > Index > indextools, un fork de imakeidx

Autre chemin : (Aller directement au contenu de l'article)

indextools, un fork de imakeidx

dimanche 25 janvier 2015, mise à jour vendredi 23 janvier 2015, par Maïeul
Suivre la vie du site RSS 2.0 Forum

À mon grand regret j’ai du, pour la première fois de ma vie, créé un fork d’un package. Le package imakeidx a dont une nouvelle version : indextools.

La raison technique

La raison technique de cette fork est la suivante : lorsqu’on utile hyperref en combinaison avec un package d’indexation, il est conseillé de charger hyperref après le package, pour avoir des liens internes.

Cependant hyperref doit être chargé avant bidi, le package qui permet de gérer les langues qui s’écrivent de droite à gauche. Ce qui fait que l’ordre de chargement correct est :

  • imakeidx
  • hyperref
  • bidi

Malheureusement, bidi redéfinie la manière dont est affichée l’index, ce qui entraîne pour conséquent que certaine fonctionnalité de imakeidx, notamment le reformatage de l’index, ne sont plus prises en compte.

Pour résoudre ce problème, il fallait donc modifier imakeidx pour que ce dernier définisse l’affichage de l’index lors du \begin{document}, dont après bidi.

La raison humaine

Ayant trouvé ce bug, je l’ai signalé à l’auteur d’imakeidx. Celui-ci n’a pas daigné me répondre, même pour me dire, par exemple, que ma solution était mauvaise. Juste ... rien, pas de réponse.

Je l’ai donc contacté via un réseau public pour :

  • lui demander pourquoi il ne répondait pas
  • si c’était par manque de temps pour s’occuper d’imakeidx, s’il souhaitait me déléguer la gestion du package.
  • sinon, s’il comptait intégrer une correction de ce bug.

L’auteur n’a pas répondu ni à la première ni à la troisième question. Quant à la seconde, il a indiqué, séchement, qu’il ne souhaitait pas que je reprenne le package.

Il a sans doute ses raisons, mais en attendant un bug existe, et je trouve idiot de laisse un package ainsi bugué.

C’est pourquoi j’ai, avec regret, décidé de forker le projet, c’est à dire d’en faire une version divergente de la version principale. Ce fork est donc sorti : indextools.

Pour le moment il se contente de résoudre ce bug. J’espère qu’un jour nous n’aurons plus qu’un seul package. En attendant, ceux qui souhaitent utiliser les fonctionnalités de bidi, hyperref et imakeidx en même temps peuvent utilise indextools.

Vos commentaires

  • Le 27 janvier 2015 à 10:48, par Robert Alessi En réponse à : indextools, un fork de imakeidx

    Ce travail était vraiment nécessaire !

    J’ai une question de portée générale. Pour mes travaux longs, j’utilise la classe memoir qui a son propre mécanisme d’indexation. Cela faisait d’ailleurs partie des premières recommandations du package ledmac. Mais pour des travaux plus courts, j’utilise régulièrement scrbook ou scrarctl qui n’intègrent pas un mécanisme tel que celui de memoir. Voici donc ma question : quelle solution doit-on préférer quand on utilise eledmac ? Une classe n’intégrant pas de mécanisme d’indexation + indextools, ou bien memoir et son mécanisme intégré ?

  • Le 27 janvier 2015 à 11:06, par Maïeul En réponse à : indextools, un fork de imakeidx

    Le rapport de (e)ledmac avec memoir est un rapport complexe. Il se trouve que que l’auteur de memoir et l’auteur de ledmac sont la même personne. Or memoir s’avère très dérogatoire sur les fonctionnement standards (que cela soit pour l’indexation et la gestion des notes). Et si (e)ledmac intègre le comportement de memoir dans son code, c’est à chaque fois sous forme de dérogation, ce qui implique de penser pour un certain nombre de choses à modifier les dérogations lorsqu’on améliore eledmac.

    Bref, en tant que repreneur de (e)ledmac, je ne suis pas super enthousiasmé par memoir. Je ne compte pas le nombre de bug spécifique à memoir. Pas plus tard que la résolution d’un bug sorti en 1.16.

    Cela étant dit, nombre de personnes utilisent memoir. Fut un temps le comportement de eledmac était le suivant : utiliser le mécanisme interne de memoir si on a affaire à memoir, utiliser celui de imakeidx dans le cas contraire. Il se trouve que j’avais mal implémenté les choses, d’où un bug (https://github.com/maieul/ledmac/issues/216).

    Donc depuis la version 1.14.0 le comportement de eledmac est le suivant :

    • si imakeidx/indextools est chargé, utiliser ses commandes pour gérer l’indexation avec ligne et numéro de page. Et ce quelque soit la classe utilisée.
    • si imakeidx/indextools n’est pas chargé :
      • utiliser le mécanisme de memoir pour gérer l’indexation multiple si memoir est utilisé
      • pas d’indexation multiple possible sans memoir.
  • Le 27 janvier 2015 à 11:36, par Robert Alessi En réponse à : indextools, un fork de imakeidx

    Oui, je vois bien, car j’utilise en fait le système depuis... edmac !

    Personnellement, je trouve qu’il est toujours préférable d’utiliser plusieurs packages, chacun pour un travail particulier, plutôt qu’un gros package censé tout prendre en charge.

    Je vais donc passer dans un premier temps à la solution memoir + indextools, puis dans un second temps vérifier si j’utilise des fonctionnalités particulières de memoir qui m’empêchent de changer. Comme j’ai indexé un très grand nombre de mots arabes dans mon édition, je pourrai faire un test en grand de ces mécanismes.

    Utiliser une classe telle que scrbook serait ton conseil ? J’aime bien la façon dont elle est conçue. Ou bien une autre classe de document ?

  • Le 27 janvier 2015 à 11:44, par Maïeul En réponse à : indextools, un fork de imakeidx

    je suis tout à fait d’accord sur le principe de plusieurs packages plutôt qu’un seul. C’est d’ailleurs un des souci de eledmac, il fait trop de chose, même si l’ensemble est relativement bien intégré.

    Pour ce qui est des classes, j’ai personnellement toujours utilisé book adapté à mes propres besoins. Je ne connais pas scrbook, donc je n’ai pas vraiment de conseil à donner.

  • Le 27 janvier 2015 à 12:00, par Maïeul En réponse à : indextools, un fork de imakeidx

    tiens, j’ai une question qui me vient à l’esprit : comment t’arrange tu avec les éditeurs en lettre, qui acceptent rarement du .tex ?

  • Le 27 janvier 2015 à 12:01, par Robert Alessi En réponse à : indextools, un fork de imakeidx

    Merci de cette réponse très intéressante. Utiliser book, c’est en effet rester au plus près de ce qui est standard : je vais réviser de très près tout ce que j’ai fait dans ce sens. Et aussi adapter le cours que je donne à mes étudiants. D’ailleurs, on peut utiliser la plupart des fonctions de scrbook sans utiliser pour autant scrbook, puisqu’elles existent sous forme de packages séparés. C’est la bonne philosophie.

  • Le 27 janvier 2015 à 12:04, par Robert Alessi En réponse à : indextools, un fork de imakeidx

    Veux-tu parler des éditeurs de texte ?

  • Le 27 janvier 2015 à 12:17, par Maïeul En réponse à : indextools, un fork de imakeidx

    je veux parler des éditeurs commerciaux (Brepols, Budé) etc, qui demandent très souvent du word et ne veulent ni tex ni PDf.

  • Le 27 janvier 2015 à 13:08, par Robert Alessi En réponse à : indextools, un fork de imakeidx

    Grande question ! En fait, je rencontre deux cas de figure :

    • celui de la publication d’articles, soit le plus souvent une vingtaine de pages. Je les convertis vers le format .odt avec pandoc qui permet même d’intégrer une bibliographie que l’on a saisie et compilée avec biblatex/biber. Inconvénient : si toutes les langues non-occidentales (grec, arabe, etc.) sont reconnues, il faut les avoir saisies en unicode dans le fichier .tex. Or je préfère coder l’arabe en arabxetex. Donc, pour ces articles, je m’oblige à la saisie unicode. Et tout passe... sauf les textes critiques saisis à l’aide de eledmac. Pour cela, une solution peu élégante : compiler le document .tex, puis remettre les (petits) passages dans le fichier .odt par copier-coller. Et confier le reste à pandoc.
    • pour les textes longs saisis avec usage massif d’eledmac : gros problème. Je ne vois que deux solutions :
      — le copier-coller massif depuis le pdf vers le .odt : c’est ce que je ferai pour mon propre texte, je pense, étant entendu que chez Budé, par exemple, ils ne veulent que du texte plus ou moins saisi au kilomètre pour éviter d’avoir à tout saisir eux-mêmes. Ensuite, ils font eux-mêmes la mise en page.
      — le refus d’obtempérer !

    Une autre solution serait d’imaginer un système de conversion. Par exemple saisir le texte critique en xml, et appliquer ensuite une transformation XSLT qui permette de passer le code soit en .tex, soit sous une forme interprétable par un traitement de texte, avec perte.

    Cela demande du temps. Mais si c’est pour se retrouver finalement sous Word, je n’en vois pas l’utilité. En revanche, on peut penser à ce type de travail pour d’autres applications. En ce moment, je construis en xml un lexique arabe-grec-arabe. Je n’en suis pas encore à écrire les transformations, mais il n’est pas impossible de penser à y intégrer des éléments de transformation vers des commandes eledmac.

  • Le 27 janvier 2015 à 13:19, par Maïeul En réponse à : indextools, un fork de imakeidx

    pour le système de conversion c’est normalement l’objet d’un de mes prochains article. Mais c’est du gros gros boulot.

    Pour pandoc je n’ai jamais réussi à mettre en œuvre. Cela bloquait soit sur biblatex soit sur le grec unicode...

    est-ce que tu pourrais faire un tutoriel ? c’est un problème récurrent et qui je pense intéresserai plus d’une personne. L’idée serait de montrer comment cela fonctionne avec :

    • unicode (grec, typiquement)
    • biblatex+biber jusqu’au bout

    pour eledmac, je pense qu’une solution serait de surcharger les commandes pour avoir quelque chose différent, par exemple faire des appels de notes plutôt que de la lineation...

    le refus d’obtempérer est une solution qui me plairait bien, mais en tant que doctorant je peux difficilement me permettre de me mettre en porte à faux avec mes éditeurs

  • Le 27 janvier 2015 à 13:29, par Robert Alessi En réponse à : indextools, un fork de imakeidx

    Pour un tutoriel sur pandoc, c’ est d’accord. Je le commence ce soir, et j’y intégrerai plusieurs exemples concrets.

    Pour la conversion, oui, en effet, je crois que ceux qui travaillent sous traitement de texte font en fait des notes de bas de page. Ensuite, les éditeurs reprennent tout cela dans leur système. Mais c’est beaucoup de travail, surtout un travail dont le résultat est une forme d’abandon par rapport à un système qui permet de faire des réalisations extraordinaires.

    Le refus d’obtempérer marche parfois. Dans un cas que je connais, ça a marché avec un grand éditeur qui a posé comme condition que le pdf ressemble à s’y méprendre aux gabarits de la collection. Et la personne qui a refusé d’obtempérer publiait sa thèse faite sous... eledmac !

  • Le 27 janvier 2015 à 13:56, par Maïeul En réponse à : indextools, un fork de imakeidx

    oui, je crois que j’obterais pour cela lors de la publication de la mienne (si jamais j’arrive à l’achever !).

    Évidememnt que c’est un travail stupide et inutile... mais notre monde est fait de chose totalement inutile, alors un peu plus un peu moins...

    merci encore pour la rédaction !

Qui êtes-vous ?

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.

À propos

Titulaire d’un doctorat en théologie et d’un doctorat en histoire, sous la direction conjointe de Frédéric Amsler et d’Élisabeth_Malamut, je commence à partir du 1er août 2017 un travail d’édition critique des Actes de Barnabé.

Dans le cadre de la rédaction de mon mémoire de master puis de ma thèse de doctorat, j’ai été emmené à utiliser LaTeX, et j’ai donc décider de partager mes techniques. En effet, au cours de mes premiers apprentissages, j’ai découvert que les ressources indiquant les outils pour l’utilisation de LaTeX en sciences humaines étaient rares. Ceci m’a conduit à maintenir ou créer plusieurs packages LaTeX et à donner plusieurs formations.

Par ailleurs, je suis membre actif de la communauté SPIP, au sein de laquelle j’administre le site Spip-Contrib. Je propose sur ce site quelques notes sur SPIP, en général à destination de webmestre.

Il m’arrive également de faire un petit peu de Python, de temps en temps.

Enfin, je tiens un blog de réflexions politiques et religieuses.

Maïeul