indextools, un fork de imakeidx - commentaires

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 !

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 !

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

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.

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.

indextools, un fork de imakeidx

Veux-tu parler des éditeurs de texte ?

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.

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 ?

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.

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 ?

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.

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