Project

General

Profile

Anomalie #18652

anomalie de conversion pdf.

Added by Ludovic ARAUJO 10 months ago. Updated 4 months ago.

Status:
Clôturée
Priority:
0-Bloquant
Assignee:
Ludovic ARAUJO
Target version:
Start date:
11/02/2021
Due date:
11/05/2021
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 KB) Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036.pdf Ludovic ARAUJO, 11/02/2021 12:06 PM
testPDF_Version.8.x.pdf (5.76 KB) testPDF_Version.8.x.pdf Ludovic ARAUJO, 11/02/2021 12:06 PM
vimFix18652.png (118 KB) vimFix18652.png affichage dans VIM de la correction effectuée Quentin RIBAC, 11/04/2021 11:02 AM
Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036_copie.pdf (59.5 KB) Mon_PDF_Sans_PageBlanche_POIRELP_20210812_1036_copie.pdf PDF corrigé Quentin RIBAC, 11/04/2021 11:02 AM
Dossier d_impression_04-11-2021-7.pdf (88.4 KB) Dossier d_impression_04-11-2021-7.pdf dossier d’impression correct Quentin RIBAC, 11/04/2021 11:02 AM
9660

History

#2 Updated by Ludovic ARAUJO 10 months ago

  • Description updated (diff)
  • Priority changed from 2-Sérieux to 0-Bloquant

#3 Updated by Madina Makhmutova 10 months ago

  • Due date changed from 11/05/2021 to 11/16/2021
  • Status changed from A qualifier to En cours

#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.

#6 Updated by Madina Makhmutova 10 months ago

  • Due date changed from 11/16/2021 to 11/05/2021

#7 Updated by Quentin RIBAC 10 months ago

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 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

#9 Updated by Ludovic ARAUJO 10 months ago

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

#10 Updated by Ludovic ARAUJO 9 months ago

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

#11 Updated by Ludovic ARAUJO 9 months ago

  • Status changed from Complément d'Informations to A traiter
  • Assignee deleted (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

#16 Updated by Ludovic ARAUJO 4 months ago

  • Status changed from Complément d'Informations to Clôturée

Also available in: Atom PDF