[Bibliothek] Barcode für Delphi (Zint)

[MarcoWarm]

Major UPDATE

ab heute wird's wohl nicht mehr funktionieren - aber zumindest compiliert es

Wir haben den Code jetzt insoweit angepasst, daß er jetzt keinerlei AnsiString und AnsiChar Code mehr enthält. Das heißt alle "Strings" sind intern jetzt 0-basierende Byte oder Char Arrays. Das liegt näher am C Code und sollte jetzt kompatibel mit den mobilen Plattformen sein.

Es wäre nett, wenn das jemand verifizieren könnte (iOS oder Android) - auch, ob sich diese erstellten Barcodes auch scannen lassen (nicht alles was dicke und dünne Striche hat ist ein lesbarer Barcode )

Außerdem werden jetzt die Gs1 Composite Barcodes unterstützt (zumindest EAN128) http://www.dlsoft.com/barcode_types/...de_symbols.htm

schönes Wochenende
Marco

PS @ achim - das zint_metafile war deprecated... in der aktuellen revision ist es nicht mehr dabei ... war noch eine Leiche .. danke fürs bescheid geben

[0815achim]

OK!

Danke für die schnelle Antwort.

Gruß... 0815achim

[0815achim]

Hallo

Ich schon wieder.
Erst mal mein Lob für die klasse Arbeit und die Muhe.

Ich habe beim rumprobieren noch einen kleinen Fehler entdeckt.
Beim erzeugen von DataMatrix wird in der generierten Grafik immer ein "@" angehängt.

Den Fehler selber habe ich im zint_dmatrix.pas Teil gefunden.
Dort steht in Zeile 479 "while (sp <= inputlen) do".
Richtig wäre aber "while (sp < inputlen) do".

Viele Grüße... 0815achim

[Furtbichler]

Zitat von MarcoWarm:

..auch, ob sich diese erstellten Barcodes auch scannen lassen (nicht alles was dicke und dünne Striche hat ist ein lesbarer Barcode )

Wenn ihr pixelgenau rendert, dann solltet ihr doch einen Unittest schreiben können, denn bitmapbasierte Barcodeencoder APIs sollte es doch geben, oder? Nur so ne Idee.

Und falls ihr wider erwarte nicht pixelgenau rendert (also die Strich- und Zwischenraumdicken auf pixel herunterrechnet und ggf. anpasst), dann garantiere ich euch, das eure Barcodes nicht immer lesbar sind (genaugenommen nur mit hochauflösenden Druckern).

Und leider bzw. gott-sei-dank gibt es auch bei Scannern gute und schlechte (wobei die schlechten nach Spec decoden, was ja nicht gerade 'schlecht' ist) und die guten eine Art Fuzzy Logic haben ('sieht am ehesten nach EAN aus, ist zwar außerhalb der Spec, aber lesbar')

Nur die 'guten' lesen auch schlecht gerenderte Barcodes (d.h. nicht pixelgenau) und das auch nicht immer. Leider. Ich kenne ein Gerät von SICK, welches neben dem Lesen auch eine Analyse der Barcodegüte ausspuckt. Aber das kostet ne Ecke.

Das war mein Senf zum Donnerstag.

[weisswe]

[QUOTE=Furtbichler;1226571]

Zitat von MarcoWarm:

Und leider bzw. gott-sei-dank gibt es auch bei Scannern gute und schlechte (wobei die schlechten nach Spec decoden, was ja nicht gerade 'schlecht' ist) und die guten eine Art Fuzzy Logic haben ('sieht am ehesten nach EAN aus, ist zwar außerhalb der Spec, aber lesbar')

Ich habe einmal auf einem Whiteboard händisch einen Barcode gemalt - auch dieser konnte von unseren Barcodescannern gelesen werden. Die waren wirklich "fuzzy"..

[Nintendo]

Wie ich das verstanden habe, kann man mit ZInt Barcodes erstellen.

Ich könnte aber ein Leseprogramm dafür gebrauchen, sofern eine gewöhnliche Webcam zum Lesen genügt oder ein Handscanner nicht teurer ist als so eine Webcam.

Was gibt es da?

Testweise ZInt runterladen scheitert an dem Unstand das ich hier jede .pas Datei einzeln holen muss. Was, wenn diese Bibliothek dann wirklich nur die Codes erstellen kann, ohne sie auch lesen zu können.

Wenn es passendes gibt, interessiert mich ein Link zu einer Datenbank mit den Zuordnungen zu den Artikeln, die mit dem Barcode codiert sind. Und zwar für Asien.

Wer kann mir einen Link senden?

[Codehunter]

Zitat von Nintendo:

Ich könnte aber ein Leseprogramm dafür gebrauchen, sofern eine gewöhnliche Webcam zum Lesen genügt oder ein Handscanner nicht teurer ist als so eine Webcam.

Kabelgebundene Scanner sind billiger als Webcams. Man muss nur schauen welche Codierungen und welche Auflösungen sie beherrschen.

Zitat von Nintendo:

Testweise ZInt runterladen scheitert an dem Unstand das ich hier jede .pas Datei einzeln holen muss.

Bequemlichkeit ist eine Zier, doch Fehl am Platze hier. Stichwort TortoiseSVN o.Ä.

[Codehunter]

@chaosben: Ich hab zwei Tage gebastelt um Zint testweise in unser System zu integrieren. Ich muss mich da korrigieren, das mit den Start-Stop-Chars stimmt doch. Unsere Scanner (Psion EP10) scheinen diese Zeichen aber schon vor dem Tastaturpuffer wegzufiltern (scheinbar über die Firmware vom Scannermodul), darum sieht man in den gelesenen Rohdaten keine Start-Stop-Zeichen.

Insofern muss ich mich entschuldigen, du solltest das wieder auf den Ausgangszustand zurück ändern.

[chaosben]

@Codehunter: kein Problem. Ich habs wieder rückgängig gemacht. Und danke für die Rückmeldung.

[Codehunter]

Eventuell wäre eine etwas präzisere Fehlermeldung an der Stelle sinnvoll. Nicht einfach nur "Invalid characters" sondern etwas das dediziert auf die fehlenden/falschen Start-Stop-Zeichen hinweist.

Tatsächlich gibt es keine technische Notwendigkeit für diese Zeichen, sondern es ist einfach eine Festlegung der Unternehmen, welche die Codierung einsetzen.

Aber an der Stelle mal dickes Lob bzgl. des WMF-Exports: Ein durchschnittlicher Druckauftrag für Etikettenbögen ist jetzt vom bisherigen Volumen von ca. 23 MB auf 870 kB zusammengeschrumpft. Das hat ganz konkrete Auswirkungen auf den Arbeitsfluss. Ich denke, im nächsten großen Release wird Zint die alte Barcode-Komponente ablösen.

Was aber noch sehr wünschenswert wäre: Eine Delphi-Komponente, welche die native Zint-Bibliothek kapselt. Im Moment ist es mehr ein Copy&Paste-Programmieren aus der Demo heraus.