Probleme mit erstellten PDFs bei LL27+LL28 (Adobe Reader auf Android / IPhone)

Hallo,

Wir haben letztes Jahr ein Update der ListLabel-Komponente in unserer Software vorgenommen (von Version 18.000 auf Version 27.003).
Die Umstellung verlief im Großteil problemlos, jedoch sind bei unseren Kunden im Einsatz vereinzelt Probleme mit den daraus erstellten PDFs festgestellt worden.

Die mit der neuen Version erstellten PDFs werden auf Mobilgeräten (getestet mit Android 11 und IPhone) beim Öffnen mit der offiziellen Adobe Acrobat Reader App nicht korrekt angezeigt.
Beim Öffnen der PDFs wird ein Großteil der enthaltenen Elemente nicht dargestellt, stattdessen hat man leere Flächen.
Alternative Anwendungen (z.B. Google Drive auf Android oder die IPhone-eigene PDF-Anzeige) stellen diese PDFs allerdings korrekt dar.

Dieses Verhalten konnte mit der Rechnung.blg aus der Beispielanwendung der jeweiligen ListLabel-Version reproduziert werden.
Die aus LL18 erzeugte PDF wird korrekt dargestellt, die aus LL27.003, LL27.004 und LL28.001 erstellten PDFs sind in der Adobe-App komplett leer, in Google Drive allerdings lesbar.

Hier macht auch die Festlegung der PDF-Version auf 1.4 keinen Unterschied (Standard bei LL18 war 1.4, bei LL27+LL28 ist es 1.7).

Bei IPhone-Benutzern ist dies zwar aufgrund der vorhandenen (und funktionierenden) Standard-Anzeige weniger ein Problem, jedoch ist auf Android aufgrund des Fehlens einer solchen Standard-App oft die Adobe-App installiert, und mit dieser sollten PDFs eigentlich auch korrekt dargestellt werden.

Welche Ursache kann es haben, dass hier bestimmte Elemente angezeigt werden, andere jedoch nicht?
Vor allem in dem Zusammenhang, dass es in den Beispiel-Reports auch auftritt und hier sogar gar nichts angezeigt wird außer leeren Seiten.

Nachfolgend die Anzeige in den Apps (neue Benutzer können nur 1 Bild hochladen, daher zusammengeschnitten zu einem Bild).

  1. Anzeige unseres Auftrags mit LL27 in der Adobe-App
  2. Anzeige unseres Auftrags mit LL27 in Google Drive
  3. Anzeige der aus Rechnung.blg erstellten PDF mit LL18 in Adobe Acrobat Reader
  4. Anzeige der aus Rechnung.blg erstellten PDF mit LL28 in Adobe Acrobat Reader
  5. Anzeige der aus Rechnung.blg erstellten PDF mit LL28 in Google Drive

Hallo,

herzlich Willkommen in der List & Label Community.

Anhand der Erklärung scheint es als hätte die Adobe App ein Problem mit der Anzeige der PDF-Dokumente, da andere Viewer (Google, PDF Viewer von Apple) es korrekt anzeigen zu können. In diesem Fall wäre das ein Fall für den Adobe Support.

Mit LL26 haben wir die PDF-Exporter Komponente komplett erneuert. Sie könnten testhalber einmal prüfen, ob die Verwendung des “alten” Exporters in diesem Fall Abhilfe schaffen kann. Diesen können Sie auf dem System, auf welchen die PDF-Dokumente erstellt werden, per Registry-Switch aktivieren:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\combit\cmbtll]
"PDF.LegacyRenderingMode"="T"

Damit lassen sich die PDF-Dokumente auch in der Adobe Reader App korrekt anzeigen.

Der Screenshot zeigt die Adobe Reader App unter iOS 16.3.1.

Danke für die schnelle Antwort.

Die so erstellten PDFs werden wieder korrekt angezeigt, als Workaround ist dies für den Moment einsetzbar.
Allerdings ist das ja eine benutzerweite Einstellung, eine entsprechendes Flag oder eine Option für den Export innerhalb des Programms gibt es demnach wohl nicht.
Auch die durch den neuen Exporter eingebrachten Verbesserungen hat man mit diesem Export wahrscheinlich nicht.

Betrachtet man die Konstellation aus einer anderen Sichtweise, kann man übrigens auch argumentieren dass die Adobe-App bei mir hunderte von PDFs aus verschiedensten Quellen problemlos öffnet und bisher nur mit den neuen LL-Exporten Probleme hat.
Ob hier der Fehler an einem der Enden oder irgendwo dazwischen liegt, kann ich aktuell auch nicht beurteilen.


Bei weiteren Tests konnte ich das Problem immerhin eingrenzen und außerdem mit einem Verarbeitungsproblem in Corel Draw in Verbindung bringen.

  1. Es hängt von der Verarbeitungsreihenfolge der Objekte im Projekt ab.
    Wichtig ist hier die Reihenfolge der Objekte im Projektbaum.
    Aus diesem Grund sind in unserem Auftrag auch der Adresskopf, die Seitenzahl und das Logo noch vorhanden, statt komplett leer dargestellt zu werden.
    Das Textfeld oberhalb der Adresskopfs folgt in der Objektliste auf den Adresskopf und ist das erste Element welches nicht mehr angezeigt wird.
  2. Es betrifft nur bestimmte Schriftarten.
    Das Formular verwendet die (auch eingebetteten) Schriftarten Arial, Arial Bold, Arial Narrow.
    Das erwähnte Feld oberhalb des Adresskopfes verwendet als einziges Feld Arial Narrow.
    Ändert man dies auf Arial, wird das erzeugte PDF vollständig in der App angezeigt.

Dahingehend habe ich die Rechnung aus der LL-Beispielanwendung für verschiedene gebräuchliche Schriftarten angepasst und exportiert mit folgendem Ergebnis in der Adobe-App:
Calibri (Standard der Vorlage) - leer
Arial - normale Anzeige
Arial Narrow - leer
Cambria - leer
Garamond - normale Anzeige
Georgia - normale Anzeige
Helvetica - normale Anzeige
Times New Roman - leer
Trebuchet MS - normale Anzeige
Verdana - normale Anzeige

Das Problem scheint hier also entweder beim Einbetten oder beim Auslesen bestimmter Schriftarten aufzutreten.


Zum Verarbeitungsproblem in Corel Draw (PDF-Import, reproduziert mit Version 2020 und 2022):

Die mit dem neuen Export aus LL 27.003 erstellten PDFs können generell nicht in Corel Draw importiert werden.
Hier erhält man grundsätzlich die Fehlermeldung “Datei ist beschädigt”.
Dies wurde wahrscheinlich durch den CapHeight-Fix in 27.004 behoben, da dieser Fix fehlgeschlagene PDF-Validation erwähnt.

Die aus LL 27.004 und LL 28.001 erstellten PDFs können importiert werden, hier erhält man allerdings oft Warnmeldungen, dass Schriftarten nicht gefunden werden konnten.
Dies betrifft wiederum nicht alle Schriftarten, allerdings scheint der Import gegenüber der Schriftarten noch wählerischer zu sein als die Adobe-App.

Beim Import unserer Datei werden Arial und Arial Bold aus der PDF erkannt, Arial Narrow aber nicht.
Beim Import der LL-Beispielrechnung wird Calibri Bold aus der PDF erkannt, Calibri aber nicht
Bei Helvetica werden weder Helvetica noch Helvetica Bold erkannt.

Im LegacyMode erstellte PDFs werden ohne jegliche Warnmeldung übernommen.

Das Problem scheint hier in beiden Fällen einen Teil der Identity-H-kodierten Schriftarten zu betreffen.
Der LegacyMode bettet soweit erkennbar nur Ansi-Schriftarten ein, darum treten die Probleme bei diesem wahrscheinlich nicht auf.

Weitere Untersuchung der Problematiken.

Das Problem mit dem Corel-Draw-Import ist doch etwas weitreichender und scheint am Import selbst zu liegen, dies können wir für den Moment außen vorlassen. Dies ist aktuell auch kein pressierendes Thema.

Zum Problem mit der Adobe-Reader-App habe ich die eingebetteten Schriftarten-Objekte untersucht und hier Gemeinsamkeiten bei den funktionierenden und nicht funktionierenden Schriftarten festgestellt.

Hier ein Auszug einiger der Schriftart-Objekte, zur besseren Übersicht wurde das Glyphenbreiten-Array (/W) weggelassen:

/Type=/Font
/Subtype=/CIDFontType2
/BaseFont=/BDCYZD+Arial,Bold
/CIDSystemInfo=<< /Ordering (Identity) /Registry (Adobe) /Supplement 0 >>
/FontDescriptor=<< /Ascent 905 /AvgWidth 479 /Descent 212 /Flags 32 /FontBBox [ 0 212 2628 905 ] /FontFamily (Arial) /FontFile2 9 0 R /FontName /BDCYZD+Arial,Bold /FontWeight 700 /ItalicAngle 0 /Leading 33 /MaxWidth 2628 /StemV 0 /Type /FontDescriptor >>
/CIDToGIDMap=/Identity
/DW=750

/Type=/Font
/Subtype=/CIDFontType2
/BaseFont=/BGITYD+ArialNarrow
/CIDSystemInfo=<< /Ordering (Identity) /Registry (Adobe) /Supplement 0 >>
/FontDescriptor=<< /Ascent 922 /AvgWidth 362 /Descent 210 /Flags 32 /FontBBox [ 0 210 1182 922 ] /FontFamily (Arial Narrow) /FontFile2 16 0 R /FontName /BGITYD+ArialNarrow /FontWeight 400 /ItalicAngle 0 /Leading 15 /MaxWidth 1182 /StemV 0 /Type /FontDescriptor >>
/CIDToGIDMap=/Identity
/DW=228.027

/Type=/Font
/Subtype=/CIDFontType2
/BaseFont=/ACTDTU+Calibri
/CIDSystemInfo=<< /Ordering (Identity) /Registry (Adobe) /Supplement 0 >>
/FontDescriptor=<< /Ascent 952 /AvgWidth 521 /CapHeight 500 /Descent 269 /Flags 32 /FontBBox [ -503 -313 1240 1026 ] /FontFamily (Calibri) /FontFile2 7 0 R /FontName /ACTDTU+Calibri /FontWeight 400 /ItalicAngle 0 /MaxWidth 1743 /StemV 0 /Type /FontDescriptor /XHeight 221 >>
/CIDToGIDMap=/Identity
/DW=506.836

/Type=/Font
/Subtype=/CIDFontType2
/BaseFont=/ASPCAN+Calibri,Bold
/CIDSystemInfo=<< /Ordering (Identity) /Registry (Adobe) /Supplement 0 >>
/FontDescriptor=<< /Ascent 952 /AvgWidth 536 /CapHeight 500 /Descent 269 /Flags 32 /FontBBox [ -519 -349 1263 1039 ] /FontFamily (Calibri) /FontFile2 13 0 R /FontName /ASPCAN+Calibri,Bold /FontWeight 700 /ItalicAngle 0 /MaxWidth 1781 /StemV 0 /Type /FontDescriptor /XHeight 221 >>
/CIDToGIDMap=/Identity
/DW=506.836

/Type=/Font
/Subtype=/CIDFontType2
/BaseFont=/AGSFWB+Verdana
/CIDSystemInfo=<< /Ordering (Identity) /Registry (Adobe) /Supplement 0 >>
/FontDescriptor=<< /Ascent 1005 /AvgWidth 508 /CapHeight 500 /Descent 210 /Flags 32 /FontBBox [ -560 -303 1523 1051 ] /FontFamily (Verdana) /FontFile2 7 0 R /FontName /AGSFWB+Verdana /FontWeight 400 /ItalicAngle 0 /MaxWidth 2083 /StemV 0 /Type /FontDescriptor /XHeight 99 >>
/CIDToGIDMap=/Identity
/DW=1000

/Type=/Font
/Subtype=/CIDFontType2
/BaseFont=/ASQLCY+Verdana,Bold
/CIDSystemInfo=<< /Ordering (Identity) /Registry (Adobe) /Supplement 0 >>
/FontDescriptor=<< /Ascent 1005 /AvgWidth 568 /CapHeight 500 /Descent 210 /Flags 32 /FontBBox [ -550 -303 1707 1072 ] /FontFamily (Verdana) /FontFile2 13 0 R /FontName /ASQLCY+Verdana,Bold /FontWeight 700 /ItalicAngle 0 /MaxWidth 2257 /StemV 0 /Type /FontDescriptor /XHeight 99 >>
/CIDToGIDMap=/Identity
/DW=1000

/Type=/Font
/Subtype=/CIDFontType2
/BaseFont=/ACYUYV+Cambria
/CIDSystemInfo=<< /Ordering (Identity) /Registry (Adobe) /Supplement 0 >>
/FontDescriptor=<< /Ascent 950 /AvgWidth 615 /CapHeight 500 /Descent 222 /Flags 34 /FontBBox [ -1475 -2464 2868 3117 ] /FontFamily (Cambria) /FontFile2 7 0 R /FontName /ACYUYV+Cambria /FontWeight 400 /ItalicAngle 0 /MaxWidth 4342 /StemV 0 /Type /FontDescriptor /XHeight 172 >>
/CIDToGIDMap=/Identity
/DW=658.203

/Type=/Font
/Subtype=/CIDFontType2
/BaseFont=/BHTEOW+Cambria,Bold
/CIDSystemInfo=<< /Ordering (Identity) /Registry (Adobe) /Supplement 0 >>
/FontDescriptor=<< /Ascent 950 /AvgWidth 600 /CapHeight 500 /Descent 222 /Flags 34 /FontBBox [ -1110 -299 1373 1047 ] /FontFamily (Cambria) /FontFile2 13 0 R /FontName /BHTEOW+Cambria,Bold /FontWeight 700 /ItalicAngle 0 /MaxWidth 2482 /StemV 0 /Type /FontDescriptor /XHeight 172 >>
/CIDToGIDMap=/Identity
/DW=658.203

Bei allen funktionierenden Schriftarten hat die DW-Eigenschaft Ganzzahlwerte, bei allen nicht funktionierenden Schriftarten Dezimalwerte.

Laut der ISO-Spezifikation 32000-1 (Link zur frei verfügbaren inoffiziellen Version von Adobe: https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf#page=277 Abschnitt 9.7.4.1 auf Seite 269) beschreibt dieser Parameter die Standardbreite für Glyphen und ist ganzzahlig deklariert (dies gilt übrigens auch für die vorigen PDF-Standards bis hin zu 1.7).

Hierzu habe ich nun testweise in den erstellten PDFs bei den funktionierenden Schriftarten diesen Wert auf Dezimalwerte und bei den nicht funktionieren Schriftarten auf Ganzzahlwerte geändert.
Die zuvor korrekt dargestellten PDFs werden nun leer angezeigt, die zuvor leer angezeigten PDFs werden nun richtig dargestellt.


Demnach lässt sich das Problem auf 2 Punkte reduzieren:

  1. Die DW-Eigenschaft wird nicht zwingend dem Standard entsprechend als Ganzzahlwert im PDF abgelegt und kann demnach ungültige Werte enthalten.
    Der Fehler liegt hier also allem Anschein nach bereits in der PDF-Erstellung.
  2. Die meisten Anzeigeprogramme führen an dieser Stelle scheinbar keine strikte Prüfung durch und verarbeiten deswegen auch Dezimalwerte.
    Die mobile Adobe-Reader-App hingegen scheint (zumindest an dieser Stelle) den Wert hingen strikt zu prüfen oder als Ganzzahlwert verwenden zu wollen und bricht deswegen die Darstellung des Dokuments ab.

Vielen Dank für die Analyse, das ist sehr hilfreich. Die PDF-Generierung erfolgt bei uns über eine 3rd Party Library - aktuell kann ich nicht versprechen, mit welcher Priorität dort Änderungen vorgenommen werden, zumal ja eben die meisten Viewer an dieser Stelle kein Problem bekommen. Wir werden das Problem aber in jedem Falle weitergeben.

Als Notfall-Fallback kann wie beschrieben der “alte” PDF-Export verwendet werden, wir haben aktuell keine Pläne, diesen aus dem Produkt zu entfernen.