Anomalie #18652
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.
| Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036.pdf (59.5 KB) Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036.pdf | |||
| testPDF_Version.8.x.pdf (5.76 KB) testPDF_Version.8.x.pdf | |||
| vimFix18652.png (118 KB) vimFix18652.png | affichage dans VIM de la correction effectuée | ||
| Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036_copie.pdf (59.5 KB) Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036_copie.pdf | PDF corrigé | ||
| Dossier d_impression_04-11-2021-7.pdf (88.4 KB) Dossier d_impression_04-11-2021-7.pdf | dossier d’impression correct |
History
#4 Updated by Quentin RIBAC 10 months ago
- Status changed from En cours to En cours de dev (S)
- Assignee set to Quentin RIBAC
#5 Updated by Quentin RIBAC 10 months ago
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.
#7 Updated by Quentin RIBAC 10 months ago
- File vimFix18652.png vimFix18652.png added
- File Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036_copie.pdf Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036_copie.pdf added
- File Dossier d_impression_04-11-2021-7.pdf Dossier d_impression_04-11-2021-7.pdf added
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 ?
#8 Updated by Quentin RIBAC 10 months ago
- Status changed from En cours de dev (S) to Complément d'Informations
- Assignee changed from Quentin RIBAC to Ludovic ARAUJO
#12 Updated by Madina Makhmutova 9 months ago
- Status changed from A traiter to Complément d'Informations
- Assignee set to 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
#14 Updated by Emmanuel DILLARD 8 months ago
- Target version changed from 292 to 20.10 TMA3