Bonjour
Erreur Java 504.
Il est possible de rencontrer des fichiers odt devant lequel
writer2xhtml s'étouffe silencieusement. Si l'on utilise le menu Fichier/export/EPUB,
writer2xhtml devient plus disert et affiche une mystérieuse erreur Java 504 face à laquelle LibreOffice rend les armes. Vous savez quoi? Calibre convertit benoîtement ce même fichier.
Voir copies d'écran pour les messages d'erreur.
N'en tirez pas de conclusion hâtive. En fait,
writer2xhtml dispose au moins de deux façons de faire de même. Si vous sélectionnez l'option "Original formatting" au lieu de "custom," ou si vous choisissez dans les options de formatage "Convert all" au lieu de "Ignore hard formatting",
writer2xhtml convertira lui aussi le fichier odt tout comme Calibre.
Avec un ami qui a bien voulu m'aider, nous avons cherché à en savoir plus:
I. - L'enquête. 
A la sortie de l'OCR, on obtient en général un fichier au format html accompagné d'un dossier "files" contenant des images aux tailles réduites. Lorsqu'on affiche ce fichier html (avec Firefox ou LibreOffice), on peut voir que ces images, quelle que soit leur largeur, sont placées avec leurs légendes dans un cadre de 18 cm. Le fichier html doit être importé dans un modèle odt pour y être mis en forme. Les images pourraient y être utilisées, après avoir été extraites de leur cadre. Cependant, comme elles souffrent de défauts de cadrage, l'ebookeur consciencieux préfèrera les écarter et travailler à partir des images du scan à haute résolution qu'il recadrera, réduira puis réinsèrera une par une.
Une façon sûre de procéder est d'insérer ces nouvelles images en les accrochant à un paragraphe centré. Le fichier odt en question contenait 35 images. Une seule n'était pas accrochée à un paragraphe centré, ce qui indiquait que le crochet original avait été conservé. C'est là que se nichait l'erreur.
L'erreur est copiable et reproductible. Sa nature a été identifiée. Il s'agit d'attributs d'un autre monde ("font-weight-asian" et "font-weight-complex"), en fait des résidus de scan, que l'on trouve dans un style de paragraphe "corps de texte" qui sert de crochet à une image. Ces attributs ne sont lisibles que si l'on dézippe l'odt et que l'on affiche le fichier content.xml. Voir copie d'écran jointe.
Pour ôter le message d'errreur, il suffit de changer un paragraphe de texte: enlever avec Ctrl X l'image qui le recouvre, vous observez alors qu'elle était accrochée à un paragraphe corps de texte. Changez celui-ci en paragraphe centré, faites Ctrl V pour remettre l'image en place et enregistrez. L'erreur 504 n'apparaîtra plus. Il faut aussi noter qu'après conversion vers l'EPUB, ce paragraphe crochet disparaît, comme tous les paragraphes servant de crochet à une image. Vous pourrez le vérifier en regardant le code de l'EPUB sur Sigil ou l'éditeur de Calibre.
Des mesures correctives ne pourront être prises qu'au retour de l'auteur de
writer2xhtml.
II. - Les mesures prophylactiques sont simples:
C'est en quelque sorte l'équivalent informatique du lavage de mains avant de passer à table:
Pour le texte:
après avoir importé le fichier html dans l'odt, changez systématiquement le style "default" (standard) en style "corps de texte" (de votre modèle). Changez aussi le style "corps de texte" (du scan) en style "corps de texte" (de votre modèle). Cela évitera la survie potentielle d'un certain nombre de résidus.
Pour les images:
afin d'éviter l'apparition de l'erreur 504, prenez l'habitude d'accrocher vos images à un paragraphe centré. FineReader ne les utilise jamais, donc, en agissant ainsi, vous êtes sûr de jamais recycler un résidu de scan. Pour éliminer l'erreur 504 si jamais elle se présente, repérez les images qui ne sont pas accrochées à un paragraphe centré et accrochez-les à un de ceux-ci.
Si vous rencontrez une erreur 504 à la conversion (ou 503 avec OpenOffice...), conservez précieusement le fichier odt gangrené et ayez l'obligeance d'en adresser une copie.