Anomalie #18652
ferméanomalie de conversion pdf.
Description
Des problèmes de conversion de PDF surviennent avec le process soffice.
Nous avons détecté que l'anomalie vient du process soffice car pas d'anomalie avec la demo.maarchcourrier.com ou la 2010sup.maarchcourrier.com.
Le PDF 1.7 en erreur : Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036.pdf
Pour info, nous avons testé avec et sans librairie payante, le résultat est identique.
La version du PDF n'entre pas en ligne de compte, des tests ont été réussis avec un PDF témoin.
Le PDF 1.7 témoin sans erreur : testPDF_Version.8.x.pdf
L'anomalie survient quand génère le pdf du dossier de lot.
Fichiers
| Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036.pdf (59,5 ko) Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036.pdf | |||
| testPDF_Version.8.x.pdf (5,76 ko) testPDF_Version.8.x.pdf | |||
| vimFix18652.png (118 ko) vimFix18652.png | affichage dans VIM de la correction effectuée | ||
| Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036_copie.pdf (59,5 ko) Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036_copie.pdf | PDF corrigé | ||
| Dossier d_impression_04-11-2021-7.pdf (88,4 ko) Dossier d_impression_04-11-2021-7.pdf | dossier d’impression correct |
Mis à jour par Ludovic ARAUJO il y a environ 3 ans
- Description mis à jour (diff)
- Priorité changé de 2-Sérieux à 0-Bloquant
Mis à jour par Madina Makhmutova il y a environ 3 ans
- Echéance changé de 05/11/2021 à 16/11/2021
- Statut changé de A qualifier à En cours
Mis à jour par Quentin RIBAC il y a environ 3 ans
- Statut changé de En cours à R&D - En cours
- Assigné à mis à Quentin RIBAC
Mis à jour par Quentin RIBAC il y a environ 3 ans
Anomalie reproduite sur branche develop
- créer un courrier avec le PDF fourni (
Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036.pdf) - essayer de générer le dossier d’impression en incluant le document principal
- le PDF généré fait 311 octets seulement, ne comporte aucune page --> KO
Comme vu dans le code ici : https://labs.maarch.org/maarch/MaarchCourrier/-/blob/develop/src/app/resource/controllers/FolderPrintController.php#L504
Le logiciel en erreur est pdfunite fourni par poppler-utils, et non soffice.
Test de pdfunite :
$ pdfunite -v
pdfunite version 0.86.1
Copyright 2005-2020 The Poppler Developers - http://poppler.freedesktop.org
Copyright 1996-2011 Glyph & Cog, LLC
$ pdfunite Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036.pdf out.pdf
Syntax Error: Failed to parse XRef entry [2].
Syntax Error: Failed to parse XRef entry [2].
Syntax Error: Failed to parse XRef entry [2].
Syntax Error: Failed to parse XRef entry [2].
Syntax Error: Failed to parse XRef entry [2].
Syntax Error: Failed to parse XRef entry [1].
Syntax Error: Top-level pages object is wrong type (none)
Syntax Error: Failed to parse XRef entry [1].
Syntax Error: Top-level pages object is wrong type (none)
Ma version de poppler est 0.86.1 sur Ubuntu 20.04 LTS ; des versions plus récentes de poppler sont disponibles sur des versions plus récentes d’Ubuntu.
RAF :
- tester sur un poppler plus récent si le pdfunite passe avec le PDF fourni (via VM ou màj du système) ;
- si toujours pas OK, étudier l’erreur de pdfunite ci-dessus.
Mis à jour par Madina Makhmutova il y a environ 3 ans
- Echéance changé de 16/11/2021 à 05/11/2021
Mis à jour par Quentin RIBAC il y a environ 3 ans
- Fichier vimFix18652.png vimFix18652.png ajouté
- Fichier Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036_copie.pdf Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036_copie.pdf ajouté
- Fichier Dossier d_impression_04-11-2021-7.pdf Dossier d_impression_04-11-2021-7.pdf ajouté
L’erreur mentionnée par pdfunite (Syntax Error: Failed to parse XRef entry) indique que le PDF est mal formaté.
En effet, en ouvrant le PDF dans un éditeur de texte, ici vim, on voit que les deux sections xref ont des lignes qui se terminent par ^M, caractère spécial de fin de ligne windows, alors que le reste du fichier n’en comporte pas.
Correction apportée au fichier PDF : effacer les ^M présent en fin de ligne dans les deux sections xref du fichier.
Ci-joint :
- un dossier d’impression correctement généré. Aucune modification de code n’a été effectuée dans Maarch Courrier ;
- le PDF corrigé ;
- l’affichage dans VIM du fichier d’origine & du fichier corrigé côte à côte.
L’erreur vient du fichier PDF.
Ce problème survient-il uniquement avec ce fichier ou avec d’autres également ?
Mis à jour par Quentin RIBAC il y a environ 3 ans
- Statut changé de R&D - En cours à Complément d'Informations
- Assigné à changé de Quentin RIBAC à Ludovic ARAUJO
Mis à jour par Ludovic ARAUJO il y a environ 3 ans
D'après le client, plusieurs PDF auraient des anomalies.
Je me renseigne avec le client.
Mis à jour par Ludovic ARAUJO il y a environ 3 ans
Les conversions en anomalies sont principalement les fichiers Word vers pdf.
Mis à jour par Ludovic ARAUJO il y a environ 3 ans
- Statut changé de Complément d'Informations à A traiter
- Assigné à
Ludovic ARAUJOsupprimé
Mis à jour par Madina Makhmutova il y a environ 3 ans
- Statut changé de A traiter à Complément d'Informations
- Assigné à mis à Ludovic ARAUJO
Commentaire de Dev :
il faut savoir si le client injecte dans maarch le .doc ou le .pdf, c’est-à-dire si la génération du pdf incorrect est faite depuis maarch ou chez le client
pour savoir s’il faut regarder dans le code de l’application ou dans le pdf seulement
Mis à jour par Emmanuel DILLARD il y a environ 3 ans
- Version cible changé de 292 à 20.10 TMA3
Mis à jour par Ludovic ARAUJO il y a plus de 2 ans
- Statut changé de Complément d'Informations à Clôturé