Pour essayer d'organiser un peu ces erreurs, j'ai tâché de les classer par module auquel elles sont « logiquement » liées - ce qui ne veut pas dire que l'erreur soit effectivement due à ce module, mais plutôt qu'elle se manifeste lors de l'utilisation de ce module ou d'éléments liés à ce module. Pour chaque erreur, j'essaye de donner quelques astuces pour les contourner ou pour en corriger les effets, ainsi que les versions dans lesquelles elle apparaît et la première version corrigée, à ma connaissance tout au moins.
Avant de commencer la liste : deux modules vite indispensables, BOMBADIL (livré avec Calamus depuis la version SL 96, ou téléchargeable depuis le site d'Adequate System) qui permet de corriger quelques-unes des erreurs de Calamus ainsi que de réparer les documents corrompus dans pas mal de cas, et DOKTOR (livré avec Calamus depuis la version SL 98) qui permet de réparer des documents, en particulier ceux venant de Calamus pour Windows (qui est, paraît-il, complètement bogué au niveau de la création des objets vectoriels...). Ces deux modules sont SHAREWARE : n'oubliez pas de vous enregistrer !
Toutes ces erreurs ont déjà été signalées à Invers (peut-être même suis-je à l'origine de leur correction, qui sait ? C'est fou ce que je suis modeste... :-), ainsi que pas mal d'autres que je ne détaille pas ici parce qu'elles n'ont aucune influence sur la structure du document ou le comportement de Calamus (erreurs dans l'interface essentiellement). Je ne reprends ici que les erreurs qui endommagent le document, font planter Calamus ou produisent un résultat inattendu. Si vous connaissez d'autres erreurs, merci de m'en faire part, avec une explication détaillée et, si nécessaire, un document d'exemple avec ses fontes, je ferai suivre à Invers (ou vous pouvez aussi l'envoyer directement par courrier électronique : voir leur adresse sur leur site.
Une dernière remarque : ne comptez pas trop sur la sauvegarde automatique en _CRASH_n_.CDK : c'est peut-être parce que je joue de malchance, mais d'une part toutes les erreurs (pouvant détruire un document) ne conduisent pas toujours à un plantage de Calamus (donc pas de sauvegarde en _CRASH_n_.CDK), d'autre part cette sauvegarde arrive souvent trop tard et le document sauvé est inutilisable parce que déjà corrompu. Il arrive aussi que le plantage soit si grave que Calamus ne puisse même pas sauver : soit il entre dans une boucle sans fin, soit la tentative de sauvegarde conduit à une nouvelle erreur qui demande une sauvegarde qui... Bref, mieux vaut prévenir que guérir et sauver avant les opérations dangereuses (et j'espère que la suite de ce document vous aidera à mieux les cerner, bien que je ne prétende pas être exhaustif, malheureusement).
Je précise enfin que lorsque je dis « toute version », cela sous-entend jusqu'à la SL98 d'avril incluse je n'ai pas encore eu le temps de vérifier l'existence de ces erreurs dans la version d'août 98 - a fortiori dans les suivantes...
Je ne parlerai ici, sauf exception, que des version 2 et 5 complètes d'Eddie, les seules que j'ai suffisamment utilisées pour pouvoir en parler raisonnablement. Il est probable que les mêmes symptômes se produisent pour les versions intermédiaires et pour les versions restreintes (si la fonction s'applique).
Ayant depuis longtemps renoncé à utiliser PKS Write, je me contenterai de deux petites remarques seulement. D'une part, il est définitivement incapable d'éditer un texte contenant des ancrages. D'autre part, invers considère que PKS-Write est extrêmement bogué et a arrêté son développement, estimant qu'Eddie fait mieux en plus sûr et que continuer à travailler sur PKS Write serait une perte de temps (je partage d'ailleurs cet avis). Ceci explique aussi pourquoi ce n'est plus PKS Write mais une version restreinte d'Eddie qui est fournie avec la version 98. Autrement, le seul souvenir qu'il m'a laissé est qu'il rend facilement inexploitables les textes un peu longs en réattribuant de façon à peu près aléatoire les styles de texte... Un assez mauvais souvenir donc.
IMPORTANT ! Si vous avez Eddie 2 en version française et une version récente de Calamus (SL96 d'octobre 1997 ou plus), n'éditez et n'insérez jamais un numéro de chapitre dans Eddie. Une erreur dans le ressource traduit conduit à une boucle sans fin de Calamus et il faut faire un reset de l'ordinateur. Le ressource est corrigé depuis la version 3.
En essayant d'ouvrir un texte dans Eddie, la fenêtre se referme aussitôt. Variante : la fin du texte est extravagante (nombreux codes de contrôles de la forme [?0] par exemple).
Le problème ne vient pas d'Eddie, mais du texte à éditer qui a été corrompu pour une raison ou une autre. Parmi les raisons répertoriées :
Attention ! Si vous essayez d'éditer le texte directement dans le module texte ou styles de texte, vous vous exposez à un plantage grave de Calamus. Mieux vaut entreprendre rapidement le remède décrit ci-dessous.
Il est assez long, mais probablement moins que recommencer entièrement le document, ou (avec un peu de chance) la chaîne de texte déjà faite, s'il était déjà presque fini. Bon courage d'avance.
Cela paraît long et compliqué comme ça, mais ça rend de fiers services quand le texte corrompu a une mise en page complexe (et en particulier des ancrages dont l'original n'est plus hors du texte et qu'il faudrait donc refaire aussi).
Bien évidemment, je ne garantis pas le moins du monde que cette méthode fonctionne dans tous les cas de corruption.
D'après le support d'Invers, exporter le texte au format CTD puis le réimporter peut aussi résoudre certains problèmes de ce type.
En refermant Eddie, une erreur « structure du document altérée. Code erreur x » apparaît.
Il est difficile d'en donner un général, l'origine de cette erreur pouvant être variable (ce qui se traduit par des valeurs de x différentes). Je donne ici deux cas que je me rappelle.
Si cette erreur se produit après avoir réalisé des corrections dans des notes de bas de page, en particulier des modifications de style, les risques de perdre des informations sont assez grands. Il faut immédiatement appeler bombadil et demander à corriger la liste de styles de texte - puis éventuellement recorriger la note, en général l'erreur ne se reproduit plus.
Un autre cas, assez vicieux, que j'ai rencontré venait d'une erreur dans le formateur de textes, qui n'aimait pas la succession [réglette][style de texte] dans certaines configurations particulières. Dans ce cas, le plus simple et de remplacer ces séquences par les séquences, équivalentes, [style de texte][réglette].
Le problème avec les notes semble être apparu avec la version 5 d'Eddie et sa possibilité d'éditer un style de texte depuis la liste des styles qu'il propose (mais sans garantie) ; n'ayant pas encore pu le reproduire de façon prédictible, sa correction est incertaine dans un avenir proche...
L'erreur du formateur de texte doit être corrigée dans la version d'avril 98 de Calamus.
En déplaçant un bloc faisant une ligne, Eddie commence une boucle sans fin avec apparition de la barre de progression.
Ceci arrive en fait quand le bloc déplacé correspond à l'avant-dernier paragraphe Calamus, tenant sur une ligne de la fenêtre Eddie, et est déplacé après le dernier paragraphe Calamus tenant lui aussi sur une ligne. Un tel déplacement doit donc être fait directement dans le module texte.
Dans la version 2, il est impossible d'interrompre la boucle et il faut faire un reset de l'ordinateur. Dans la version 3 light, la boucle peut s'interrompre avec Ctrl-Shift-Alt comme marqué dans la barre de progression. Dans la version 5, l'erreur est corrigée. Je ne me rappelle plus du tout ce que donne la version 4.
Bien que voulant désactiver le bloc, il reste affiché comme actif dans la fenêtre principale (mais les marques de début et de fin ont bien disparues dans la loupe texte, en haut à gauche).
Cette erreur est juste visuelle ; je ne me souviens plus de la façon exacte de la reproduire - mais adequate systems est au courant et m'a assuré que l'erreur serait corrigée rapidement.
Mis en évidence dans la version 5, mais il existe probablement avant. Devrait être corrigé dans la prochaine version (6).
En déplaçant des ensembles de lignes correspondant à des paragraphes Calamus, il apparaît un ensemble de codes de contrôles étranges, Eddie ne va plus à la ligne pour certains codes de fin de ligne et déplacer le curseur dans le texte montre une « boucle » de texte.
Exporter immédiatement le texte dans le cadre (une boîte d'alerte vous y invite d'ailleurs dans la version 4) : le texte est correct et peut ensuite être retravaillé normalement.
Attention ! Ne surtout pas essayer de redimensionner la fenêtre Eddie, cela risque de provoquer un plantage sévère de Calamus.
Mis en évidence avec la 2, existe jusqu'à la 5 incluse, adequate systems a réussi à la reproduire donc travaille dessus (la reproduction de l'erreur a été très délicate car elle dépend fortement de la taille de la fenêtre Eddie, donc de la résolution utilisée, et de l'ordre des déplacements effectués...)
En effectuant une recherche (avec ou sans remplacement) contenant des espaces de largeur fixe imposée par l'utilisateur (quart de cadratin, tiers de cadratin,...), certaines occurences ne sont pas trouvées.
Quand ces espaces sont insérés directement depuis le module texte, l'un des deux paramètres (sans utilité) est mal initialisé Eddie, lors de la recherche, vérifie aussi ce paramètre et ne trouve donc pas ces espaces exactement identiques à celui du masque de recherche.
Le plus simple est de mettre à jour Eddie : la version 5 ne vérifie plus la valeur de ce paramètre lors de la recherche.
Une autre possibilité est de remplacer, dans le masque de recherche, l'espace en question par un joker correspondant à tous ces types espaces. Cela nécessite la version complète d'Eddie et, bien sûr, que la recherche n'ait pas pour but de distinguer des espaces de valeurs différentes...
Du côté Eddie, depuis la version 5 le paramètre inutile n'est plus pris ne compte et les espaces sont correctement trouvées
Du côté Calamus, depuis la version 98 le paramètre est correctement initialisé.
Au cours d'une recherche avec remplacement, Calamus se bloque et refuse de rendre la main. Le curseur de la souris à la forme d'une page, comme lors du reformatage d'une page. La seule façon de reprendre la main est de faire un reset de l'ordinateur.
Malheureusement, je n'ai pas de remède efficace : je n'ai pas réussi à comprendre dans quel cas cette erreur arrivait, même si j'ai réussi à créer un document où elle apparaît systématiquement (Adequate Systems devrait donc être un train de plancher dessus...). Il semble néanmoins que les risques soient fortement diminués si le texte a été exporté dans son cadre juste avant de lancer la recherche, et que plus la recherche est complexe (en particulier lors de l'utilisation de plusieurs critères à la suite) et conduit à des modifications importantes du texte, plus il y a de risques de voir apparaître le problème. Après avoir renvoyé le texte dans le cadre, profitez-en pour sauver...
J'ai rencontré ce problème la première fois avec la version 4 d'Eddie, mais il est possible qu'elle existe dans les versions précédentes (de façon plus discrete cependant). Il est toujours présent dans la dernière version 5 que j'ai reçue ; il faut dire que je n'ai réussi à le reproduire qu'il y a quelques semaines, même si je l'ai signalé avant...
En essayant d'agrandir un cadre par le haut (resp. par la gauche) pour le faire coller à une ligne d'aide horizontale (resp. verticale) magnétique située au-dessus (resp. plus à gauche), le cadre est déplacé sans que sa taille soit modifiée.
Pas de véritable remède à ce jour. Pensez bien à d'abord coller le coin supérieur gauche puis à agrandir par le coin opposé, et non l'inverse, pour ne pas perdre de temps à cause de cette erreur.
Mis en évidence sur la SL96 de janvier 1997 (allemande), mais probablement aussi dans les versions précédentes toujours pas corrigé dans la version d'août 98 (ce n'est pas faute de leur rappeler, pourtant...)
En essayant de coller un cadre sur la grille pour des positions négatives, le résultat est farfelu.
Essayer, en utilisant la périodicité de la grille, de placer son origine le plus près possible du coin supérieur gauche de la page (coordonnée (0,0)), même si cela oblige parfois à des calculs supplémentaires.
Remarque. En mode recto/verso, la grille est toujours symétrique par rapport à la reliure. L'espace entre deux filets verticaux de la grille n'est donc pas nécessairement égal au pas en X de la grille lorsque l'on franchit cette reliure... Cela peut surprendre, au début, même si c'est cohérent avec le système de coordonnées par défaut de Calamus.
Mis en évidence dans la version SL 96, probablement présent auparavant. Corrigé depuis la SL 98 (fin 97 ou avril 98, je ne sais plus).
Ces fonctions ont été ajoutées dans la version 96, donc les erreurs signalées dans la suite de ce paragraphe n'existent pas dans les versions antérieures... (jolie lapalissade, non ?)
Réaliser une copie virtuelle d'un cadre texte possédant un fond conduit à une erreur « structure du document altérée. Code erreur x ».
Aucun une fois l'erreur apparue, à ma connaissance... Méfiance donc en copiant un cadre texte. Sinon, il faut mettre à jour Calamus pour ne pas avoir le problème.
Corrigé depuis la version d'octobre 97 - comme c'est la première version française officiellement distribuée, cette erreur ne concerne en fait que les gens qui possèdent une version allemande antérieure ; je la cite surtout pour mémoire... et parce que c'est la première erreur que j'ai signalée à invers et par conséquent le début de mon travail de bêta-testeur... Nostalgie...
En réalisant la rotation d'un cadre texte avec fond, le fond est tourné deux fois plus que le cadre texte.
Préférer les cadres groupés aux cadres textes avec fond, si le but est de les faire tourner (même si c'est un peu moins pratique parce que le fond n'est pas mis automatiquement à la taille du cadre texte).
Corrigée depuis la version d'août de la SL 98.
Le chemin formant l'objet n'apparaît pas, ou il se place en (0, 0) en quittant ce sous-module
Le module vectoriel se comporte très mal lorsque le grossissement est trop important (la limite exacte, de l'ordre de 3000%, dépend du document).
Cela semble corrigé depuis la SL 98.
À l'impression, des objets en pointillés apparaissent avec seulement de toutes petites portions dessinées (essayez un grossissement de 600% sur un cadre surface, cercle, de 0,5 cm de côté, surface blanche, côté noir en pointillés épais de 0,2 mm, pour voir ce que je veux dire...)
L'erreur est due à de mauvais arrondis dans les routines vectorielles (je pense...). La règle essentielle : ce qui sera imprimé est ce qui est visible lors d'un grossissement "Imprimé 1:1", donc bien regarder ce qui se passe à ce grossissement pour être tranquille.
En général, changer la taille ou l'épaisseur de quelques dixièmes de millimètres améliore beaucoup les choses.
À ma connaissance, toutes versions. L'erreur ne disparaitra, comme d'autres de ce genre (limitation à 32000*32000 pixels) qu'avec l'apparition de nouvelles routines vectorielles (selon le responsable du projet Calamus) - peut-être la version XL de Calamus ?
Voilà, mes connaissances sur les erreurs de Calamus s'arrêtent ici. Si vous en connaissez d'autres, n'hésitez pas à m'en faire part. J'espère que la lecture de cette page vous évitera les rares manœuvres qui conduisent à des résultats plus ou moins désastreux avec calamus. Une dernière remarque : si vous travaillez avec Magic Mac, évitez absolument les allers-retours entre MacOS et Magic (pomme-W), cela semble favoriser grandement l'apparition de plantages aléatoires avec Calamus (je ne sais pas si les choses se sont améliorées avec la version pour MacOS 8 de magic, mais dans le doute... les auteurs de calamus conviennent eux-même de la grande instabilité de calamus dans ces conditions et rejettent la faute sur magic. Je préfère ne pas prendre parti...).