Projet

Général

Profil

Anomalie #18652

anomalie de conversion pdf.

Ajouté par Ludovic ARAUJO il y a plus de 2 ans. Mis à jour il y a environ 2 ans.

Statut:
Clôturé
Priorité:
0-Bloquant
Assigné à:
Ludovic ARAUJO
Version cible:
20.10 TMA3
Début:
02/11/2021
Echéance:
05/11/2021
Version applicable MC:
Tags Courrier:

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 ko) Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036.pdf Ludovic ARAUJO, 02/11/2021 12:06
testPDF_Version.8.x.pdf (5,76 ko) testPDF_Version.8.x.pdf Ludovic ARAUJO, 02/11/2021 12:06
vimFix18652.png (118 ko) vimFix18652.png affichage dans VIM de la correction effectuée Quentin RIBAC, 04/11/2021 11:02
Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036_copie.pdf (59,5 ko) Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036_copie.pdf PDF corrigé Quentin RIBAC, 04/11/2021 11:02
Dossier d_impression_04-11-2021-7.pdf (88,4 ko) Dossier d_impression_04-11-2021-7.pdf dossier d’impression correct Quentin RIBAC, 04/11/2021 11:02
9660

Historique

#2 Mis à jour par Ludovic ARAUJO il y a plus de 2 ans

  • Description mis à jour (diff)
  • Priorité changé de 2-Sérieux à 0-Bloquant

#3 Mis à jour par Madina Makhmutova il y a plus de 2 ans

  • Echéance changé de 05/11/2021 à 16/11/2021
  • Statut changé de A qualifier à En cours

#4 Mis à jour par Quentin RIBAC il y a plus de 2 ans

  • Statut changé de En cours à R&D - En cours
  • Assigné à mis à Quentin RIBAC

#5 Mis à jour par Quentin RIBAC il y a plus de 2 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.

#6 Mis à jour par Madina Makhmutova il y a plus de 2 ans

  • Echéance changé de 16/11/2021 à 05/11/2021

#7 Mis à jour par Quentin RIBAC il y a plus de 2 ans

9660

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 Mis à jour par Quentin RIBAC il y a plus de 2 ans

  • Statut changé de R&D - En cours à Complément d'Informations
  • Assigné à changé de Quentin RIBAC à Ludovic ARAUJO

#9 Mis à jour par Ludovic ARAUJO il y a plus de 2 ans

D'après le client, plusieurs PDF auraient des anomalies.
Je me renseigne avec le client.

#10 Mis à jour par Ludovic ARAUJO il y a plus de 2 ans

Les conversions en anomalies sont principalement les fichiers Word vers pdf.

#11 Mis à jour par Ludovic ARAUJO il y a plus de 2 ans

  • Statut changé de Complément d'Informations à A traiter
  • Assigné à Ludovic ARAUJO supprimé

#12 Mis à jour par Madina Makhmutova il y a plus de 2 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

#14 Mis à jour par Emmanuel DILLARD il y a plus de 2 ans

  • Version cible changé de 292 à 20.10 TMA3

#16 Mis à jour par Ludovic ARAUJO il y a environ 2 ans

  • Statut changé de Complément d'Informations à Clôturé

Formats disponibles : Atom PDF