welcome: please sign in
location: Änderungen von "PaperlessOffice"
Unterschiede zwischen den Revisionen 21 und 22
⇤ ← Revision 21 vom 2017-07-11 14:17:51 →
Größe: 9203
Autor: hayd@cbs.mpg.de
Kommentar:
← Revision 22 vom 2017-07-17 11:44:14 → ⇥
Größe: 9661
Autor: hayd@cbs.mpg.de
Kommentar:
Gelöschter Text ist auf diese Art markiert. Hinzugefügter Text ist auf diese Art markiert.
Zeile 74: Zeile 74:
siehe auch:
 * [[http://www.slub-dresden.de/ueber-uns/slubarchiv/technische-standards-fuer-die-ablieferung-von-digitalen-dokumenten/langzeitarchivfaehige-dateiformate/|Langzeitarchivfähige Dateiformate]]
 * [[http://www.slub-dresden.de/service/pflichtmedien-abliefern/technische-standards-fuer-die-ablieferung-von-netzpublikationen/|Technische Standards für die Ablieferung von Netzpublikationen]] - u.a. Tipps zur Erstellung PDF/A-konformer Dateien
 * freier [[http://www.linux-magazin.de/NEWS/PDF-A-Validator-Vera-PDF-in-Version-1.0|PDF/A-Validator Vera PDF]] - bietet [[http://verapdf.org/software/|Installer]] für Linux
 * [[https://de.wikipedia.org/wiki/JHOVE|JHOVE]] - in Projekt, um ein erweiterbares Tool zur Formatvalidierung zu entwickeln		 == Validierung des PDF/A ==
Zeile 80: Zeile 76:
Wenn das PDF/A nicht dem Standard entspricht, wird es über kurz oder lang Probleme geben, die nur mit viel Arbeit zu beheben sind. Man sollte daher [[http://www.slub-dresden.de/ueber-uns/slubarchiv/technische-standards-fuer-die-ablieferung-von-digitalen-dokumenten/langzeitarchivfaehige-dateiformate/|langzeitarchivfähige Dateiformate]] einsetzen - am besten [[http://www.slub-dresden.de/fileadmin/groups/slubsite/Service/PDF_Service/Einf%C3%BChrende_Informationen_zum_PDFA-Standard.pdf|PDF/A-2a]].

Wenn das PDF/A nicht dem [[http://www.slub-dresden.de/service/pflichtmedien-abliefern/technische-standards-fuer-die-ablieferung-von-netzpublikationen/|Standard]] entspricht, wird es über kurz oder lang Probleme geben, die nur mit viel Arbeit zu beheben sind.

Mit einem PDF/A-Validator sollte man daher überprüfen, ob es sich wirklich um ein standardkonformes PDF/A handelt:
 * [[https://de.wikipedia.org/wiki/JHOVE|Jhove:]] "Für die Validierung von PDF/A-Dateien ist es [[http://www.slub-dresden.de/fileadmin/groups/slubsite/Service/PDF_Service/Einf%C3%BChrende_Informationen_zum_PDFA-Standard.pdf|nicht wirklich geeignet]]"
 * Man verwende daher veraPDF:
  * Bericht im [[http://www.linux-magazin.de/NEWS/PDF-A-Validator-Vera-PDF-in-Version-1.0|Linux-Magazin, 12.1.2017]]
  * [[http://verapdf.org/2017/01/10/verapdf-1-0-released/|veraPDF]] ist ein freier Validator für PDF/A
  * [[http://verapdf.org/software/|Download]]

Papierloses Büro

Konzept zur Realisierung eines papierlosen Büros

Inhaltsverzeichnis

  1. Papierloses Büro
    1. Architektur, Workflow
    2. Scannen
    3. Nachbearbeitung der Scans
    4. OCR
    5. Erkanntes in PDF integrieren
    6. Validierung des PDF/A
    7. Erkanntes indexieren
    8. Misc
    9. RPi zur Bedienung des Scanners
    10. Siehe auch
    11. Offene Fragen
    12. Anmerkungen, Anregungen

Architektur, Workflow

paperless.png

  • Die Scans werden in einem lokalen Verzeichnis (raw) gespeichert und im Archiv abgelegt.
    • Da dieser Schritt aufwändig ist, soll er bei Bedarf (z.B. höhere Auflösung, mehr Farben erforderlich) nicht wiederholt werden müssen, sondern man kann die Scans aus dem HSM holen.
  • Die Scans werden in ein anderes lokales Verzeichnis (work) kopiert, in dem folgende Bearbeitungsschritte erfolgen:

    • ggfs. Reduzierung der Auflösung und der Farben mit ImageMagick

    • Entfernung von Artefakten (Dreck)
    • Entfernung von leeren Seiten
    • OCR
    • Erzeugung von PDF/A
    • Indexierung
  • Die Dokumente (PDF/A) und ihr Index werden in ein ownCloud-Verzeichnis bei der GWDG (final) synchronisiert.
  • Man sucht und betrachtet die Dokumente per Web-Interface in "final". Bei Bedarf kann man sich einzelne Unterverzeichnisse auf einen lokalen Rechner synchronisieren.

  • inotify meldet einen neuen File und stößt nächsten Schritt an.

  • Für jede Nutzergruppe/Scanner (= ACL-Kombination) gibt es eine eigene Verarbeitungskette.
  • Die Zugriffsrechte werden mit den Bordmitteln von ownCloud geregelt.

Scannen

Einscannen mit Raspberry Pi, Ubuntu-PC und Scanner

Nachbearbeitung der Scans

  • unpaper (home) - Kommandozeilenprogramm zur Nachbearbeitung von fotokopierten/gescannten Bild- und Textvorlagen.

  • unpaper wird wohl nicht mehr weiterentwickelt, so dass imagemagick eine Alternative wäre, z.B. despeckle

OCR

Erkanntes in PDF integrieren

  • mit PDF/A-1a – Level A (Accessible) conformance: sowohl eindeutige visuelle Reproduzierbarkeit als auch Abbildbarkeit von Text nach Unicode und inhaltliche Strukturierung des Dokuments, so dass es im Sinne der Barrierefreiheit von einem Screenreader vorgelesen werden kann.

  • OCRmyPDF - Kommandozeilenprogramm, um für eingescannte PDF-Dateien eine durchsuchbare Textebene zu erstellen. OCRmyPDF wandelt das PDF eines Scans in PDF/A und macht dabei u.a.: Geradeziehen, Säubern, OCR, PDF/A-Validierung.

  • hocr2pdf - hocr2pdf kann aus hOCR-Seiten(informationsreiches HTML-Format, welches u.a. Tesseract ab Version 3.0x liefert) und der dazugehörigen Bilddatei eine durchsuchbare PDF-Datei zu erstellen.

Validierung des PDF/A

Man sollte daher langzeitarchivfähige Dateiformate einsetzen - am besten PDF/A-2a.

Wenn das PDF/A nicht dem Standard entspricht, wird es über kurz oder lang Probleme geben, die nur mit viel Arbeit zu beheben sind.

Mit einem PDF/A-Validator sollte man daher überprüfen, ob es sich wirklich um ein standardkonformes PDF/A handelt:

Erkanntes indexieren

Volltextsuche mit Recoll - Dieser Beitrag erläutert die Einrichtung bis zum Ausbau als Dokumentenzentrale im Netz mit Hilfe von Recoll WebUI

  • recoll verarbeitet im Netzwerk auch Anfragen über den Webbrowser.
  • indexiert (mit geeigneten Filtern): .pdf, .doc, .tar, .zip, .ps, .rtf, .tex, .txt, .html, ...
  • ggfs. 1x/h incrementelle Indexierung anstoßen

offene Fragen:

  • Index über alle finalen Ordner (Problem: Man kann finden, was man nicht lesen darf.) oder für jede Nutzergruppe einzeln. Problem: Man muss mehrmals suchen. Man sollte mit wenigen Nutzergruppen (Direktoren, Mitarbeiter) arbeiten, so dass diese wissen, wo sie suchen müssen bzw. ggfs. muss man nicht oft suchen.

Misc

Präferierte Hardware:

RPi zur Bedienung des Scanners

Siehe auch

  • Paperwork ist ein in Python verfasstes Programm zur Digitalisierung, Indexierung und Archivierung von Dokumenten aller Art. Das Programm befindet sich noch in einer frühen Entwicklungsphase. Es ist wohl eher für den Desktop (GUI) als für ein Netz geeignet. Wäre aber vielleicht für einen Check direkt nach dem Scannen geeignet.

Offene Fragen

  • Scannen
    • Welche Scanner verwenden?
    • Mit wieviel dpi scannen? Soll zukunftssicher sein. Kann in einem nächsten Schritt heruntergereechnet werden.
    • Mit wieviel Farben scannen? Soll zukunftssicher sein. Kann in einem nächsten Schritt heruntergereechnet werden.
    • In welchem Format sollen diese Rohdaten archiviert werden?

    • Wie kann man einen RPi mit LCP-Display (oder diesem Display) zur Steuerung des Scanners nutzen? Die Daten sollen dann vom RPi auf einen Ubuntu-Server zur Weiterverarbeitung übertragen werden.

  • Post-Processing der Scans
    • Mit welchen Tools erledigt man am besten folgende Aufgaben im Processing:
      • Geraderücken
      • Ränder entfernen, wenn z.B. nur eine Visitenkarte eingescannt wurde
      • Falten, Dreck, Grauschleier entfernen

Anmerkungen, Anregungen

Anmerkungen, Anregungen, Verbesserungsvorschläge hinterlasse man bitte auf der Diskussionsseite

PaperlessOffice (zuletzt geändert am 2018-09-12 13:16:17 durch thenmarkus@cbs.mpg.de)