Elektronische Ablage / Digitales Archiv

Briefe, Rechnungen, Dokumente, Bedienungsanleitungen, Veränderungsmitteilungen als Briefpost oder als Anlage zu einer E-Mail. Zudem interessante Zeitungsartikel oder Kochrezepte. Das eine wird abgeheftet, dass andere auf den "Stapel" gelegt und das alles in / an verschiedenen Ordnern / Orten. Manches "verschwindet" auch einfach und landet im Altpapier oder gerät in Vergessenheit. Wenn dann mal etwas gesucht wird, geht es los. Alle naselang muss abgeheftet werden, um die Ordnung halbwegs zu bewahren, aber dennoch wird die schiere Masse immer größer.

Aus diesem Grund wuchs in mir der Wunsch nach einer strukturierten und durchsuchbaren "digitalen Ablage" für all dieses analoge (aber auch digitale) Schriftgut.

  • Vorhaben/Ziel/Ist-Zustand
  • Planung
  • Hardware
  • Software
  • Probleme
  • Noch zu tun
  • Links
  • Vorhaben/Ziel/Ist-Zustand

    Ziel ist nicht im Privaten ein Dokumenten-Management-System (DMS) zu etablieren. Ein DMS ist nämlich viel mehr als nur eine Ablage. Es dient vorrangig dem Zweck, für z.B. sich wiederholende Vorgänge einen "Workflow" anzubieten. Hierbei wird insbesondere auch ein Rechtemanagement, Unterschriftsbefugnisse sowie Versionierung der Dokumente abgedeckt.

    Dies alles brauche ich nicht für meinen privaten Schriftverkehr (was bei Ihnen durchaus anders sein kann).

    Andererseits stand ich vor der Entscheidung meine bisherige "analoge Ablage" (auch z.B. für die digital erhaltenen Rechnungen, Mails mit Anlagen usw. die ich für die analoge Ablage ja bisher ausgedruckt habe) zu vergrößern (was auch mit Kosten verbunden wäre für z.B. Regal, Schrank, Registraturen, Mappen usw.) oder neue Dokumente (zumindest den größten Teil, egal ob per Brief-Post oder elektronisch) gleich in einer digitalen Ablage zu überführen. Ausnahmen werden lediglich für wesentliche Dokumente gemacht wie z.B. Urkunden, wichtige Verträge (z.B. notarieller Art) und Versicherungsscheine sowie Unterlagen, die z.B. das Finanzamt gerne im Original hätte.

    Das Ganze musste dann auch unter Linux laufen bzw. funktionieren.

    Vorhanden war neben dem PC auch ein A4-Flachbettscanner (mit LED, also ohne Aufwärmzeit), ein Negativ-/Film- bzw. Dia-Scanner (Reflecta) und die Scan-Software VueScan, welche ich für die Digitalisierung meiner Fotos unter Linux lizenziert hatte (Pro-Version mit Lifetime-Updates). Mittels VueScan kann man auch (bei entsprechenden Einstellungen) durchsuchbare PDFs von Schriftgut erzeugen.

    Planung

    Grob plante ich - ähnlich wie bei digiKam, das ich schon seit Jahren für die Archivierung meiner digitalen Fotos (incl. gescannter Dias, Negative und Fotos) nutzte - eine Ablage in einer entsprechenden Verzeichnisstruktur. Natürlich hätte ich auch eines der verfügbaren DMS-Verfahren für diesen Zweck einsetzen bzw. zweckentfremden können, aber dies widerspräche dem "Kiss-Prinzip" (keep it simple and smart). Alle mir bekannten DMS-Verfahren nutzen eine Datenbank, nicht nur für Metainformationen. Dies hätte zu weiteren Abhängigkeiten bei zukünftigen Systemumstellungen (neuer PC mit neuem OS usw.) geführt.

    Mir ist bewusst, dass diese DM-Systeme auch Vorteile bieten, aber dennoch wäre das für mich "mit Kanonen auf Spatzen schießen" bzw. "Overkill" gewesen.

    Zudem war für die Massendigitalisierung von Schriftgut ein Flachbettscanner ein nur suboptimales Gerät. Das Handling (jedes Blatt einzeln auflegen, scannen, entfernen, nächtes Blatt, evtl. mit Rückseite) wäre zeitaufwändiger gewesen, als mit einem Dokumentenscanner mit ADF sowie Duplexfähigkeit (Vor- und Rückseite werden gleichzeitig eingescannt). Für besondere Scans, z.B. aus Büchern und/oder Zeitschriften, macht ein Flachbettscanner aber durchaus Sinn, denn für die Verwendung im Dokumentenscanner mit Einzug müssten diese Printmedien erst „zerlegt“ werden.

    Hardware

    Neben dem vorhandenen PC und Flachbettscanner wäre also ein Stapelscanner ein gutes Arbeitsmittel. Zuerst hatte ich da meinen Blick auf Multifunktionsgeräte gerichtet, die aber zu dem Problem der Lauffähigkeit unter Linux noch die Eigenschaft "Kann alles, aber nicht alles richtig" besaßen. Und gerade, wenn diese Multifunktionsgeräte auch einen Stapeleinzug (ADF) besaßen, waren sie entweder in Preisregionen oberhalb des anvisierten Budgets oder hatten ein integriertes Fax an Bord, welches ich nicht wollte/brauchte. Andere Geräte vergaßen ihre Einstellungen, wenn sie vom Strom getrennt werden. Zudem hatte ich bereits einen Tintenfarbdrucker und Laser-SW-Drucker. Also wurde als nächstes das Gebiet "Dokumentenscanner mit ADF" abgegrast. Im preislichen Rahmen entdeckte ich zunächst den

    Fujitsu ScanSnap iX500

    der eigentlich recht gute Kritiken in den einschlägigen Verkaufsportalen erhalten hat. Dieser hatte zwar keine Twain-Schnittstelle, wäre aber per VueScan auch unter Linux zu betreiben gewesen (nicht aber z.B. mit Sane). Nachdem ich aber noch den

    Brother ADS-2100

    entdeckt hatte, stand meine Entscheidung fest. Letzterer bietet neben der vollen Twain-Unterstützung auch eigene Treiber für Linux (somit auch per Sane nutzbar).

    Solche - also mit nativer Unterstützung von Linux - Hardware-Hersteller kann man (also ich ;) ) nur unterstützen. Preislich liegt er auch im Rahmen und von den Anwenderkommetaren schneidet er nicht schlechter ab als der Fujitsu.

    Zusammengeklappt nimmt er am Arbeitsplatz wenig Raum in Anspruch (im Gegensatz zu einem Multifunktionsdrucker allemal). Zudem ist er auch ohne PC zu betreiben (USB-Stick rein, Scan starten und fertig), so dass ich für eine Kopie für meine Kinder nicht immer meinen eigenen PC anzuschmeißen bräuchte. Da ich auch ein Freund des Mottos "1 Funktion gleich 1 Gerät" bin, passte dieser Dokumentenscanner mit ADF besser.

    Für den Betrieb des Brother ADS-2100 müssen zunächst die „br-“ bzw. „ADS-“Treiber und Tools von der Brother-Homepage geladen, installiert und konfiguriert werden:

    - Treiber-Download
    - Installation
    - Konfiguration

    Danach ist ein Neustart des Linux-Systems erforderlich

    Hinweis: Ich habe den Brother-Scanner nach Installation der Linux-Treiber auch in einer virtuellen Maschine (Guest) mit Windows 7 auf meinem Kubuntu 12.04 LTS (Host) mittels VMware WS 10 "ans Laufen gebracht", aber erst mit den neu von der Brother-Homepage geladenen 64-Bit-Treibern für Windows 7. Nur so kann z.B. beim "Scan-to-USB-Stick" (hierbei wird auf dem USB-Stick ein Verzeichnis "Brother" angelegt und darin eine Datei mit einem mehr oder weniger zufälligen Namen) das Format von JPG auf PDF umgestellt werden.

    Software

    Die eingescannten und in PDF-Dateien umgewandelten Dokumente sollten auf jeden Fall durchsuchbar sein. Dies bedingt also optische Zeichenerkennung (OCR). Meine ersten Versuche mittels Sane, tesseract und gscan2pdf waren zwar nicht schlecht, aber die Ergebnisse (schon beim scannen, aber auch – evtl. gerade wegen der besseren Scans - die Texterkennung brachte weniger Fehler zu Tage) waren mit VueScan einfach besser (wobei sich ja auch VueScan der tesseract-Zeichenerkennung bedient). Aus diesem Grund werde ich mich auf VueScan beschränken.

    Hinweise zu VueScan:

    Für die Stapelscans ist eine Vorsortierung der Dokumente nach Größe, Textausrichtung, doppel-/einseitig, „buntheit“ und ähnlichem sehr hilfreich. So kann man für jede Dokumentenart, die sich auch wiederholt, ein spezielles Arbeitsprofil für VueScan erstellen und jederzeit wieder aufrufen.

    VueScan mit Profil "AutoScanA4-1seitig2PDFwOCRTXT.ini" <<<=== wird nachgeliefert

    Nach einem Neustart von VueScan sollte das gewünschte Scan-Profil geladen werden, weil ansonsten keine Gewähr dafür besteht, dass mit den letzten Einstellungen gescannt wird.

    Scans mit 400 dpi als PDF in 24 Bit RGB.

    Probleme

    Querformat:
    "PDF Papiergröße" im Register "Ergebnis" muss auf "Automatisch" stehen, weil sonst Dokumente im Querformat quer auf eine A4-Seite im Hochformat ausgegeben werden und OCR-Texterkennung nicht funktioniert.
    Im Register "Quelle" muss "Drehen" auf "rechts" stehen und die Querformat-Dokumente mit der rechten Kante (Druckseitig muss "oben" also nach links im Scanner eingelegt werden) zuerst eingezogen werden.
    Hierfür habe ich mir dann ein eigenes VueScan-Profil erstellt, was aber bedingt, dass man die Dokumente vor dem Scannen in Quer- (Landscape) und Hochformat (Porträt) sortiert und getrennte Stapel bildet. Gscan2pdf beherrscht meines Wissens auch OCR in alle 4 Richtungen, dies verlängert allerdings die Dauer der Texterkennung. Muss also jeder für sich entscheiden.

    Überwiegend weißes Papier (Rechnungen von Reichelt und ELV z.B.) ergeben ca. 42 bis 75 KByte große PDFs je Seite.

    "Graues" Umwelt- bzw. Recyclingpapier bzw. mehrfarbige Dokumente

    Umweltpapier und mehrfarbige Dokument (schwarz, grau und orange) ergeben PDFs von 1 MByte bis über 3 MByte (!!) pro Seite.

    Selbst ein PDF mit "8-Bit grau" statt "24 Bit RGB" verkleinert einen 23-seitigen Scan von z.B. Watterott-Rechnungen von 47,4 auf nur 44,2 MByte. Eine Erhöhung der Einstellung "PDF-Komprimierung" von "An" auf "Maximal" ergab eine Reduzierung der Dateigröße um ca. 40 % je Seite.

    PDFs splitten und zusammenfügen

    Diese Funktionalität braucht man, wenn man den Stapelscan in eine einzige PDF-Datei vorgenommen hat. Mittels VueScan kann aber auch jede Seite in eine eigene PDF umgewandelt werden. Hier ist evtl. eine Vorsortierung der zu scannenden Dokumente hilfreich/sinnvoll.

    Die erzeugten Scan-Dateien mit den mehr oder weniger vielen einzelnen Dokumenten, die mal ein- aber auch mehrseitig sein können, müssen ggfls. auf separate PDF-Dateien aufgeteilt werden. Hierzu gibt es für Linux einige Kommandozeilen-Programme (CLI), die per Befehlsoptionen (eben auf der Kommandozeile) ihre Arbeit verrichten. Ich suche aber ,da mir bei den CLI-Programmen die Voransicht fehlt und ich aus einer Scan-Datei mal einseitige aber eben auch mehrseitige PDF-Dateien erzeugen möchte (und nicht erst alles einseitig splitten und in einem nächsten Rutsch alles zusammengehörige wieder verbinden (mergen) möchte), ein grafisches Tool.

    Dies schränkt die Auswahl schon ein, es gibt aber:

    Pdf-Shuffler 0.6.0

    und

    PDF Mod 0.9.1

    Beide sind in einer halbwegs aktuellen Version über die Repositories der hier benutzten Linux-Distribution ((k)ubuntu 12.04 LTS) verfügbar.

    PDF-Shuffler ist von der Oberfläche her nicht mehr ganz auf dem Stand der Dinge, tut aber, was es soll. In den gesplitteten Dateien sind die unsichtbaren Textebenen enthalten. Die Metadaten werden aber nicht in die gesplitteten Dateien übernommen. Leider weist PDF-Shuffler nicht darauf hin, dass eine bereits bestehende Datei gleichen Namens mit dem Erzeugen einer neuen Split-/Mergedatei überschrieben wird. Dies erfordert also bei mehreren Dateien schon eine gewisse Umsicht. Zudem merkt es sich nicht den Ordner, in dem man zuletzt gearbeitet hat, so dass man bei jedem Programmstart erst wieder dahin verzweigen muss. Man kann direkt eine oder mehrere Seite(n) markieren und diese unter einem anderen Namen speichern.

    PDF Mod ist von seiner Oberfläche schon moderner gestaltet. Neben dem fast stufenlosen Zoom (<Strg>-<+>) kann man zusätzlich noch die Metadaten des PDF-Dokumentes editieren bzw. festlegen. Wurde aus der großen Sammelscan-PDF ein Dokument herausgelöst (zum splitten), werden die Metadaten ebenfalls nicht übernommen, aber man kann dem herausgelösten PDF neue Metadaten zuweisen. Zudem merkt sich PDF Mod den zuletzt benutzen Arbeitsordner. Da man erst eine Seite herauslösen muss um diese dann unter einem anderen Namen abzuspeichern, ist der Ablauf umständlicher als bei PDF-Shuffler.

    Welchem Programm man den Vorzug gibt, da wird wohl jeder seine eigenen Vorlieben haben und selbst entscheiden. Falls ich auf ein weiteres Tool stoße (aber nur mit Voransicht), wird dies hier nachgetragen.

    Wie wichtig die Metadaten sind/sein können, werde ich noch näher betrachten.

    ** Nachtrag/Einschub vom 22.02.2014: **

    Zu den Metadaten: Da das Splitten der im Stapel gescannten Dokumente sowieso die Vergabe eines Dateinamens erfordert, habe ich mir sehr schnell zu eigen gemacht, den Dateinamen (z.B. bei Rechnungen/Lieferscheinen usw.) als Ort von folgenden Angaben zu machen

  • Datum des Vorgangs/Dokuments (wegen Sortierung in der Form JJJJ-MM-TT), gefolgt von " - " (ohne die '"', also Leerzeichen, "-", Leerzeichen)
  • Name des Verkäufers, wieder gefolgt von " - "
  • Stichworte zur gelieferten Ware
  • Dateiextension (also ".pdf")
  • Bei Verkäufern, bei denen ich häufiger im Jahr etwas bestelle, spare ich mir die Angabe des Namens, da diese ein eigenes Verzeichnis, evtl. sogar mit Unterteilung in Verzeichnisse nach Jahren erhalten. Hört sich evtl. zunächst kompliziert an, hat sich bei mir aber sehr schnell eingespielt.

    Sinn ist, dass ich dadurch die Metadaten in den einzelnen PDF-Dokumenten vernachlässigen kann, denn nach Dateinamen bzw. Teilen davon lässt sich auch mit einfachen Bordwerkzeugen suchen. Und ob man jetzt Metadaten einpflegt oder die Dateinamen entsprechend vergibt, dürfte vom Aufwand her sehr ähnlich sein.

    ** Ende Nachtrag/Einschub vom 22.02.2014: **

    Textsuche über mehrere PDF-Dateien:

    Da hier wegen des Dateiformates (der Textlayer wird nicht als einfacher Text im PDF gespeichert) die üblichen Verdächtigen wie (e)grep ausscheiden, besteht die Möglichkeit mittels pdfgrep auf der Kommandozeile ganze Verzeichnisse mit PDF-Dateien nach Begriffen zu durchsuchen (die Funktionalitäten sollen ähnlich der von grep sein, also Suche mit „regular expressions“, rekursive Suche, Ausgabe des Dateinamens und der Seite, optional case-sensitive, Zähler für Häufigkeit des Suchbegriffs). Näheres, sobald ich dazu Erfahrungen gesammelt habe. In den Ubuntu-Repos ist die Version 1.2-1 vorhanden, aktuell gibt es bereits die Version 1.3.0 (Quelle).

    Wie ich gerade festgestellt habe, kann die in den Ubuntu-12.04-Repos vorhandene Version 1.2 von pdfgrep noch keine rekursive Suche (also über mehrere Verzeichnisse). Deshalb habe ich mir aus der o.a. Quelle die Version 1.3 (ab Ubuntu 12.10 in den Repos) installiert (vorher aber noch über den bevorzugten Paketmanager (apt-get, synaptic und Co.) die Pakete poppler-cpp0 und poppler-cpp-dev installieren, sonst wird das nichts). Die Version 1.2 habe ich bei der Gelegenheit zuerst noch deinstalliert, damit sich diese Versionen nicht gegenseitig behindern bzw. stören.

    Da die Installation aus den Quellen die ausführbare Datei nach /usr/local/bin/pdfgrep kopiert und diese nicht im Suchpfad eines normalen Benutzers liegt, habe ich noch einen Link nach /usr/sbin/pdfgrep erzeugt. Damit sollten auch zukünftige Updates funktionieren.

    Erste "Gehversuche" mit pdfgrep zeigen eine gute Verarbeitungsgeschwindigkeit.

    Eine Eingabe von z.B.:


    pdfgrep -H -R HDMI "/daten/E-Ablage/30 - Andere Rechnungen/FlussInSüdamerika/"


    zeigt mir z.B. jedes Vorkommen der Zeichenkette "HDMI" in den Dateien unterhalb des Verzeichnisses und allen Unterverzeichnissen von "/daten/E-Ablage/30 - Rechnungen/FlussInSüdamerika/". Für jedes Vorkommen wird die Datei bzw. deren Name gelistet. Dies kann natürlich - je nach Inhalt der Datei - auch zu einer Mehrfachnennung von Dateien führen.

    Achtung: Der Verzeichnisname ist wegen der vorhandenen Leerzeichen in '"' gesetzt.

    Noch zu tun

    Falls Sie "auf den Geschmack" gekommen sein sollten: Ein drängendes "To Do" ist das Thema Backup. Dies ist bei mir zunächst erst einmal nachrangig, da ich das gescannte Schriftgut (noch) nicht vernichte. Noch packe ich die gescannten Dokumente in einen A4-Umschlag, versehe diesen mit dem Datum des Scanns und packe diese Umschläge in eine Aufbewahrungskiste. Dabei werde ich auch ein Vernichtungsdatum notieren, denn (erledigte/abgeschlossene) Kaufvertrags-Rechnungen länger als 3 volle Kalenderjahre aufzubewahren ist in DE wegen der hierfür geltenden Verjährungsfristen nicht erforderlich. Evtl. Garantie-/Gewährleistungsansprüche sind dann in der Regel auch weggefallen. Anderslautende Verträge / Vorgänge sollten separat (auch in der digitalen Ablage) gehandhabt bzw. im Original aufbewahrt werden.

    Links:

    VueScan
    PdfShuffler
    PDF Mod
    pdfgrep
    gscan2pdf
    tesseract
    Brother ADS-2100