Hallo. Ich möchte bei meinem Projekt auf allen generierten Dokumenten zwei Barcodes anbringen. Der erste Barcode ermöglicht es, das Dokument erneut abzurufen. Es enthält eine URL samt der dazu erforderlichen Parameter. Dieser Code kann dann durch Smartphone oder Webcam Scanner eingelesen werden um den Link zu erhalten. Der zweite Code speichert für die Erstellung des Dokumentes relavante Daten, er enthält in codierter Form einige Datensätze, die für die erneute Erzeugung des Dokumentes erforderlich sind. Auch wenn der zugehörige Account beteits gelöscht oder geändert wurde, soll eine Wiederherstellung des Dokuments ermöglicht werden. Ohne auf Backups zurückgreifen zu müssen oder die Datensätze durch manuelle Eingabe anhand der gedruckten Kopie "wiederherstellen" zu müssen. Zum Beispiel ist die Adresse, das Datum, das Produkt mit Preis und die Gesamtsumme sowie verschiedene Nummern in dem Code maschinenlesbar codiert. Nun gibt es ja verschiedene Barcode Systeme. QR Code, DataMatrix, Aztec und auch noch PDF417. Die verschiedenen Codes haben Vor-und Nachteile. Folgende Vor-und Nachteile habe ich bisher ermittelt: QR-Code: Guter "Wiedererkennungswert" durch weite Verbreitung und markantes Aussehen. Viele "Smartphonereader" oder PC Reader unterstützen dieses Vormat. Eignet sich hervorragend, um den "Servicelink" zu codieren, mit dem ein erneuter Abruf der PDF Datei möglich ist, solange sie noch nicht gelöscht ist. Man findet auch viele Informationen und Beispiele zur Implementierung. Auch fertige Encoderbibliotheken in OpenSource. Bei iQR mittlerweile auch rechteckige Codes möglich, verbesserung der Speicherkapazität. Leider noch nicht so gut dokumentiert und noch nicht so als "OpenSource" verfügbar. DataMatrix: Älteres Verfahren, im europäischen Raum weit verbreitet. Ermöglicht auch rechteckige Formen. Den "Backupcode" könnte man damit gut am Seitenrand einbinden. Ist auch gut dokumentiert, offener Standard. OpenSource Encoder verfübar. Oft geht leider nur die quadratische Form Problemlos. Speicherkapazität höher als klassicher QR, aber weniger als iQR Aztec: Neueres Verfahren, hohe Speicherkapazität. Leider nur Quadratische Formen möglich. PDF417: Gut dokumentiert, OpenSource verfügbar. Rechteckige Form. Leider geringe Speicherkapazität. Nun, welchen Code würdet ihr verwenden? Für den Servicelink tendiere ich zu QR, wegen dem Wiedererkennungswert. Als "Speichermedium" würde ich eigentlich gerne den iQR nehmen, aber weil ich da noch keine gute Dokumentation und OpenSource Lösungen gefunden habe, müsste ich etwas anderes nehmen.
Ich benutze in einem Projekt Qr-Codes. Geht wunderbar, wie du schon bemerkt hast gibts jede Menge Implementierungen. Gruß Jonas
Ja, QR Code hat schon einige Vorteile gegenüber den beiden Anderen. Vor Allem. wenn man den neuen I-QR schon mit berücksichtigt. Die Offenlegung durch Denso Wave und Aufnahme als IEC Standard ist geplant, wenn man sich so im Internet umschaut. Daher ist dann auch mit offenen Implementionen für IQR zu rechnen. Bei dem normalen QR mit Quadratischer Form wirds schon Eng, die komplette Anschrift, Mailadresse usw maschinenlesbar einzucodieren, um aus der Papierform ohne Rückgriff auf die eigentliche Datenbank wieder das Dokument in elektronischer Form generieren zu können. Das Teil wird einfach riesig. Bei rechteckiger Form ließen sich mehr Daten im linken Seitenrand unterbringen. Möglicherweise mache ich auch nen XML Export aus der Datenbank, sobald das Dokument erstellt wird. Und im TAG wird dann nur noch die XML ID gespeichert. Bei den XML Files ändert sich dann auch nix mehr, wenn sich der User löscht. Ausserdem sind einzelne, kleine Dateien für mich besser Archivierbar als ne komplette Datenbank. Mit der XML ID finde ich das dann auch noch nach längerer Zeit in nem Filesystem, da die ID dann Teil des Dateinamens wird. Hatte auch schon überlegt, bei meiner Papier-Kopie, die zu den Akten gelegt wird, auf der Rückseite den XML Export zu diesem Dokument als ganzes als Code aufzudrucken zu Backup Zwecken. (Das Teil wird dann aber relativ groß). Dann kann ich das XML File zu diesem Dokument notfalls mit dem Scanner zurückholen falls die Backups nach einigen Jahren nicht mehr lesbar / nicht mehr auffindbar sind. Einer Mysql Datenbank beim Shared Hosting traue ich eben nicht, auch wenn man da im Prinzip DB Dumps anfertigen kann.
Wozu gibts eigentlich OCR? Dass man eine Quelle (z.B. URL) angibt, kann ich ja noch nachvollziehen. ABer was soll ein Barcode bewirken, aus dem man das komplette Dokument wieder herstelle kann? Das Dokument liegt doch vor einem. Wenn man das nochmal als Datei benötigt, kann man es scannen und per OCR re-kodieren. Der Barcode ist doch nichts Anderes als eine (vereinfacht) maschinenlesbare Schrift ... Nun sind wir aber technisch bereits seit Jahren soweit, dass man auch "normale" Schrift recht gut wieder einlesen kann, zumindest gedruckte (Handschrift ist schwieriger, darum gehts hier aber nicht) ...
Läubi .. schrieb: > Sven schrieb: >> Nun, welchen Code würdet ihr verwenden? > > http://ollydbg.de/Paperbak/ :-) Genau, und der ist richtig OpenSource :D Er benutzt Komprimierung, und Redundanz, also ich denke, um Daten an den Rand zu drucken perfekt. Total einfach. Es gibt noch einen schönen Code: http://www.microglyphs.com/deutsch/html/technologie.shtml Den kannst du in ein Hintergrundbild integrieren, und keiner merkt es.
Martin G. schrieb: > Den kannst du in ein Hintergrundbild integrieren Aber vermutlich darf man da erst mal Geld für abdrücken, bevor es ans ausdrucken geht :-(
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.