Fehler #609
Nach Update von Debian11 auf Denian12 Fehler beim Ausdrucken von Rechnungen wenn ZugFerD eingeschaltert.
0%
Beschreibung
Mit der aktuellen Version von Debian 12 mit TeX Live 2022/Debian, pdfTeX 3.141592653-2.6-1.40.24 und kpathsea version 6.3.4 bekommt am beim Ausdrucken von Rechnungen als .pdf mit eingeschalteter ZugFerD Option (alle anderen Belege sind nicht betroffen) eine Fehlermeldung die wahrscheinlich von tagpdf verursacht wird.
(Fehlermeldung kann nachgereicht werden)
Historie
Von Bernd Bleßmann vor mehr als 1 Jahr aktualisiert
- Zugewiesen an
Jan Bürenwurde gelöscht
Nur als Hinweis, damit es nicht übersehen wird:
Es gibt einen Branch "f-no-tagpdf", der das Thema adressiert. In meinem kurzen Test hat das geholfen, aber ob das komplett funktioniert, kann ich nicht beurteilen. Evtl. geht was anderes kaputt.
Zudem scheint sich an dem LaTeX-Paket pdfmanagement-testphase (tetsphase!) sicher irgendwann noch was zu ändern (zumindest der Name).
Von Bernd Bleßmann vor mehr als 1 Jahr aktualisiert
Bernd Bleßmann schrieb:
Es gibt einen Branch "f-no-tagpdf", der das Thema adressiert. In meinem kurzen Test hat das geholfen, aber ob das komplett funktioniert, kann ich nicht beurteilen. Evtl. geht was anderes kaputt.
Hier fehlt zudem eine Validierung durch ein externes Zugferd-Tool o.ä.
Von Jan Büren vor mehr als 1 Jahr aktualisiert
Ich bekomme diese Ausgabe mit der aktuellen Version:<validation><pdf>
<report>
<buildInformation>
<releaseDetails id="core" version="1.12.1" buildDate="2018-05-08T18:57:00+02:00"></releaseDetails>
<releaseDetails id="validation-model" version="1.12.1" buildDate="2018-05-08T20:39:00+02:00"></releaseDetails>
</buildInformation>
<jobs>
<job>
<item size="69737">
<name>/home/jan/Downloads/Rechnung_RG20230386.pdf</name>
</item>
<validationReport profileName="PDF/A-3B validation profile" statement="PDF file is not compliant with Validation Profile requirements." isCompliant="false">
<details passedRules="120" failedRules="3" passedChecks="8313" failedChecks="3">
<rule specification="ISO 19005-3:2012" clause="6.2.11.5" testNumber="1" status="failed" passedChecks="0" failedChecks="1">
<description>For every font embedded in a conforming file and used for rendering, the glyph width information in the font dictionary and in the embedded
font program shall be consistent.</description>
<object>Glyph</object>
<test>renderingMode 3 || isWidthConsistent null || isWidthConsistent == true</test>
<check status="failed">
<context>root/document0/pages0(15 0 obj PDPage)/contentStream0(16 0 obj PDContentStream)/operators177/usedGlyphs4(PLNNBM+NimbusSanL-Regu 2 0 0)</context>
</check>
</rule>
<rule specification="ISO 19005-3:2012" clause="6.2.4.3" testNumber="3" status="failed" passedChecks="0" failedChecks="1">
<description>DeviceCMYK shall only be used if a device independent DefaultCMYK colour space has been set or if a DeviceN-based DefaultCMYK colour space
has been set when the DeviceCMYK colour space is used or the file has a PDF/A OutputIntent that contains a CMYK destination profile.</description>
<object>PDDeviceCMYK</object>
<test>gOutputCS != null && gOutputCS == "CMYK"</test>
<check status="failed">
<context>root/document0/pages0(15 0 obj PDPage)/contentStream0(16 0 obj PDContentStream)/operators9/xObject0(2 0 obj PDXForm)/contentStream0(2 0 obj PDContentStream)/operators2/xObject0(1 0 obj PDXForm)/contentStream0(1 0 obj PDContentStream)/operators316/shading0(33 0 obj PDShading)/colorSpace0(45 0 obj PDDeviceN)/alternate0</context>
</check>
</rule>
<rule specification="ISO 19005-3:2012" clause="6.2.4.4" testNumber="1" status="failed" passedChecks="0" failedChecks="1">
<description>For any spot colour used in a DeviceN or NChannel colour space, an entry in the Colorants dictionary shall be present.</description>
<object>PDDeviceN</object>
<test>areColorantsPresent == true</test>
<check status="failed">
<context>root/document0/pages0(15 0 obj PDPage)/contentStream0(16 0 obj PDContentStream)/operators9/xObject0(2 0 obj PDXForm)/contentStream0(2 0 obj PDContentStream)/operators2/xObject0(1 0 obj PDXForm)/contentStream0(1 0 obj PDContentStream)/operators316/shading0(33 0 obj PDShading)/colorSpace0(45 0 obj PDDeviceN)</context>
</check>
</rule>
</details>
</validationReport>
<duration start="1691414104146" finish="1691414105510">00:00:01.364</duration>
</job>
</jobs>
<batchSummary totalJobs="1" failedToParse="0" encrypted="0">
<validationReports compliant="0" nonCompliant="1" failedJobs="0">1</validationReports>
<featureReports failedJobs="0">0</featureReports>
<repairReports failedJobs="0">0</repairReports>
<duration start="1691414103908" finish="1691414105530">00:00:01.622</duration>
</batchSummary>
</report>
<info><signature>unknown</signature><validation><duration unit='ms'>2111</duration></validation></info><summary status='valid'/></pdf>
<xml><info><version>2</version><profile>urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended</profile><validator version="0.8.3"></validator><validation datetime="2023-08-07 15:15:12"><rules><fired>57</fired><failed>0</failed></rules><duration unit='ms'>6644</duration></validation></info><summary status='valid'/></xml><info><version>2</version><profile>urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended</profile><validator version="0.8.3"></validator><validation datetime="2023-08-07 15:15:12"><rules><fired>57</fired><failed>0</failed></rules><duration unit='ms'>6644</duration></validation></info><summary status='valid'/></validation>
Von Jan Büren vor mehr als 1 Jahr aktualisiert
- Status wurde von Neu zu Gelöst geändert
Sollte mit den Commits von gerade und dem letzten c9fd7802c993385a2a30d618 behoben sein.