Dokumenten-Management mit Paperless-NGX

Beide nicht funktionierenden Dateien haben PDF Version 1.3, die anderen sind neuer. Vielleicht liegt es ja daran…
 
Möglich, allerdings: Die Datei "Rechnung-…" hatte auch Version 1.3
Résumé: Ist das pre-consume-script aus, wurden bisher alle Dateien anstandslos konsumiert. Mit aktivem Script gehen die Dateien nicht, bei denen qpdf Warnungen á la "Object has offset 0" ausspuckt. Das muss ja dann irgendetwas Strukturelles in den pdf-Dateien sein…
Nun wäre natürlich eine Lösung schön, weil ich schon gerne das Script nutzen würde. Ich halte es für unnötig bspw. bei eingescanten 22-Seitigen AGBs, welche dummerweise nur einseitig bedruckt sind, beim späteren aufrufen und lesen jede zweite Seite überspringen zu müssen. Abgesehen von dem damit erhöhtem Platzbedarf. Der Scanner (Lexmark MC2425adw) unterstützt leider beim Scannen auf SMB das automatische entfernen von leeren Seiten nicht. Deswegen ja auch der Versuch mit dem Script von GitHub.
:kopfkratz: Was dieses bash(?)-scripting angeht bin ich leider völliger Leihe. Könnte man das nicht anpassen, dass bei solchen Warnungen zumindest das Script so übersprungen wird, dass der normale Consume-Vorgang einfach weiterläuft?
Bonusfrage: Muss man sich Sorgen machen, dass die MacOS-Interne Funktion zum pdf-export solche Fehler erzeugt (Object has Offset 0)?
Hat jemand einen link für einen guten Crashkurs für das Scripting?

Gruß
whoami
 
Zuletzt bearbeitet:
Ist das so ähnlich wie filee?
Kann jeder Scanner damit arbeiten? Wie würde der workflow ohne nas aussehen?
 
Bonusfrage: Muss man sich Sorgen machen, dass die MacOS-Interne Funktion zum pdf-export solche Fehler erzeugt (Object has Offset 0)?
Habe mittlerweile weiter dazu gesucht - die beste Erläuterung fand ich hier
https://github.com/OpenPrinting/cups/issues/321

allerdings recht weit unten im Thread(die Problemeingrenzung dauerte etwas..):
also hier: https://github.com/OpenPrinting/cups/issues/321#issuecomment-1246741326

Zusammenfassung: dumm gelaufen
1. Apple baut Mist im PDF
2. qpdf (oder eine vonqpdf genutzte Komponente) interpretiert die diesbezügliche Warnung als Fehler und bricht fälschlicherweise ab

im vorletzten Post erklärt jemand, wie er es behoben hat...
https://github.com/OpenPrinting/cups/issues/321#issuecomment-1455095622

--> CUPs in Docker aufsetzen und fixen und die Dokumente da durchjagen...
 
Danke, in die Richtung hatte ich noch nichts gefunden. Nur auch englische Erläuterungen, das es solche Fehler geben kann, die aber je nach „pdf-Interpreter“ gar nicht unbedingt auffallen, da dann wohl einfach ignoriert wird.
Dummerweise hat offensichtlich nicht nur Apple dieses Problem (bei mir macos Monterey), meine Versicherung hat mir auch schon pdf-Dateien zugesendet, die solche Fehler aufweisen.
Und wie gesagt, ohne das Script, sprich ohne Verwendung von qpdf, nimmt Paperless die auch ohne zu meckern.

Da die Lösung dort mit dem Laden und Anpassen von Sourcecode zu tun hat, würde ich davon eher Abstand nehmen. Ich schaue eher mal, ob man das Script nicht mit einer Abfrage versehen kann, ob solche Fehler in der pdf zu finden sind und dann das Script übersprungen werden kann. Wenn ich das richtig sehe, muss das Script nur mit dem „exit status 0“ durchlaufen, damit der normale Consume-Vorgang weiter geht.

Gruß
whoami
 
studibook,
ich kenne Filee nicht. Paperless-NGX läuft als Serverdienst auf einem linux. Hier mehr Infos und eine eher schlecht laufende Demonstration: https://docs.paperless-ngx.com/
Irgendwo gibt es auch Informationen zu Scannern, allerdings werden die soweit ich weiß eh nicht direkt angesprochen, sondern Paperless überwacht einen Ordner und „konsumiert“ dort abgelegte Dokumente, vorwiegend pdf-Dateien. Wie diese dort hinkommen ist Paperless relativ egal.
Hier mal eine kurze Erläuterung auf Youtube: https://youtu.be/Xl0w_8zg0Mo?si=mcwuKjPphzlmbOTV

Oder hier: https://youtu.be/ycLwmM0UZ4Q?si=PO49GZaHabtgfpag

Gruß
whoami
 
Zurück
Oben