indextools, un fork de imakeidx
RSS 2.0 ForumLa 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.
RSS 2.0
- Commentaires
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 :
# 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 :
— 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 :
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 !