BarCode erstellen??

[MeierZwoo]

Zitat von Furtbichler:

Allerdings sei angemerkt, das die weitaus meisten Barcode-Rendering Engines nicht in der Lage sind, einen Barcode pixelgenau zu erstellen. Bei niedrigen Auflösungen ist es dann nämlich möglich, das der Barcode vom Scanner nicht erkannt wird.

Fonts sind -sauber umgesetzt- pixelgenau.

Für Fonts gelten dieselben Bedingungen wie für errechnete Striche (Barcode-Rendering Engines) - die Breite des Barcodes muß an die Auflösung (schrittweise) angepaßt werden. Und bei Fonts weiß man nie, was das System in der Canvas mit Kantenglättung etc. treibt, da es ja Fonts sind und das System sie eben als solche behandelt. Deshalb bin ich der Meinung, es ist genau umgekehrt: Nur bei errechneten Strichen kann man sich auf eine saubere Ausgabe verlassen.

Und da bei fehlendem Font dann der ganze Druck abgebrochen werden muß (weil es ja zB sinnlos ist, dann nur den Barcode-Druck wegzulassen und Tausende Etiketten OHNE Barcode auszudrucken - um sie dann zu entsorgen) oder ein anderer Font mit gleichem Namen installiert wurde ...

Deshlab habe ich von Barcodefonts bisher die Finger gelassen - und die Striche lieber selber passend zur Endgeräte-Auflösung selber berechnet - ist auch System- und Geräte-unabhängig. Das mache ich seit DOS-Zeiten so und ein Test vorkurzem mit Barcodefonts hat dies wieder bestätigt: Man erreicht keine saubere Ausgabe bei minimalem Raum - nur riesen Barcodes funktionieren mit Fonts einigermaßen.

Die einzigen Barcodefonts, die sauber rauskommen, sind im Drucker installierte Fonts bzw. Algorithmen, auch weil die Drucker zu geringe oder falsche Größenvorgaben einfach ignorieren und diese dann selber setzen.

[Furtbichler]

Zitat von MeierZwoo:

Für Fonts gelten dieselben Bedingungen wie für errechnete Striche (Barcode-Rendering Engines)

Soweit ich mich erinnere, kann man für TTF sog. Hints angeben, d.h. Hilfsinformationen, die beim Rendern in geringen Auflösungen die Pixelgenauigkeit gewährleisten. Deshalb 'sauber umgesetzt', denn man muss die Hints schon angeben.

Aber im Grunde genommen hast Du Recht: Während ein korrekt gerenderter Barcode -umgerechnet- eben einfach nicht als 6pt Font darstellbar ist, würde ein auf 6pt gepresster BC-Font vermutlich grenzwertige Ergebnisse liefern, die umso besser ausfallen, je konkreter die Hints sind, aber eben nicht 100% korrekt sind und sogar zu Lesefehlern führen können (bzw. ist der BC dann gar nicht lesbar).

Ich drucke aber grundsätzlich nicht so kleine Barcodes (außer mit Thermotransfer).

Zitat:

und ein Test vorkurzem mit Barcodefonts hat dies wieder bestätigt: Man erreicht keine saubere Ausgabe bei minimalem Raum - nur riesen Barcodes funktionieren mit Fonts einigermaßen.

In den Grenzsituationen würde ich das auch so sehen. Allerdings finde ich 8pt nicht 'riesig' und mit diesen Größen -oder sagen wir lieber- Breite des schmalsten Balkens >= 3pxl geht das imho schon.

Ich korrigiere mich also: Lieber ne FR-Engine und Fonts nur als Notlösung bzw. bei Druckern mit genügender Auflösung oder normalgroßen Barcodes.

Geht die Ausgabe über einen Laserdrucker, reicht i.a. ein Font. Geht sie über Tintentrahler oder Industriedrucker mit < 150dpi würde man sich mit Fonts die Karten legen.

Wenn der Drucker nativ Barcodes drucken kann (z.B. Zebra-Drucker), dann würde ich hier sowieso eine Lösung anstreben, die dieses Feature nutzt. Und das geht selbst mit einer FR-Engine nicht.

Zitat von MeierZwoo:

Die einzigen Barcodefonts, die sauber rauskommen, sind im Drucker installierte Fonts bzw. Algorithmen, auch weil die Drucker zu geringe oder falsche Größenvorgaben einfach ignorieren und diese dann selber setzen.

Das ist allerdings nur die halbe Wahrheit (oder misverständlich): Ein BC-Renderer, der die konkrete Auflösung des Zieldruckers zum Rendern in Betracht zieht, wird auch korrekte BC erstellen. Allerdings können die dann erheblich vom im Design hinterlegten abweichen.

[MeierZwoo]

Zitat von Furtbichler:

Ich drucke aber grundsätzlich nicht so kleine Barcodes (außer mit Thermotransfer).

Ich hab das leider ständig - weil Etiketten, vorallem auf Sondermaterialien ganz schön ins Geld gehen können und dort um jeden mm gefeilscht wird.

Perlsau, einen nicht installieren (also im System angemeldeten) Font kann man aber nur verwenden, wenn die Font-Datei auch auf der Kiste vorhanden ist und niemand dran rumgefummelt hat. Und einige Benutzer treiben die merkwürdigsten Dinge - wobei das den Programmersteller ansich nicht berührt, wohl aber seinen Ruf ruiniert, vorallem wenn die Benutzer auch noch zu feige sind, zuzugestehen, daß sie rumgefummelt haben.

Das Problem bei Barcodes ist ja aber, daß niemand der Benutzer einen Fehler so einfach wie bei falschem Text erkennen kann - und auch beim wieder einscannen für Kontrollen die Zeit und Lust oder auch Möglichkeit meist nicht vorhanden ist - und dann landen völlig falsche Daten im Zielsystem.

Aus den Gründen versuche ich alle Fehlerquellen auszuschließen. Und dazu gehören Fonts, also externe Drittdateien, über die ich keinerlei Kontrolle habe.

[Perlsau]

Zitat von MeierZwoo:

Perlsau, einen nicht installieren (also im System angemeldeten) Font kann man aber nur verwenden, wenn die Font-Datei auch auf der Kiste vorhanden ist und niemand dran rumgefummelt hat. Und einige Benutzer treiben die merkwürdigsten Dinge - wobei das den Programmersteller ansich nicht berührt, wohl aber seinen Ruf ruiniert, vorallem wenn die Benutzer auch noch zu feige sind, zuzugestehen, daß sie rumgefummelt haben.

Um einen Font zu verwenden, von dem du nicht weißt, ob er auf der Zielkiste installiert ist, kopierst du die benötigte Fontdatei beim Installieren deiner Anwendung in den Anwendungsordner, genau so, wie du auch die Exe-Datei dort hineinkopierst. Damit ist die benötigte Font-Datei auf der Kiste verfügbar. Wo ist das Problem
Wenn du's nicht glaubst, dann probier's doch einfach mal aus

Daß Fonts zum Ausdrucken eines Barcodes nicht das Gelbe vom Ei sind, ist eine andere Geschichte.

[MeierZwoo]

Zitat von Perlsau:

Um einen Font zu verwenden, von dem du nicht weißt, ob er auf der Zielkiste installiert ist, kopierst du die benötigte Fontdatei beim Installieren deiner Anwendung in den Anwendungsordner, genau so, wie du auch die Exe-Datei dort hineinkopierst. Damit ist die benötigte Font-Datei auf der Kiste verfügbar. Wo ist das Problem

Sorry, aber ich bin weder der Benutzer noch der dort zuständige Admin - ICH kann NICHTS auf die Zielkiste DAUERHAFT kopieren. Dann muß ich wie oben auch schon erwähnt, den Druck abbrechen, wenn diese Datei nicht mehr vorhanden ist oder verändert wurde (also auch noch hashen).

[Perlsau]

Zitat von MeierZwoo:

Sorry, aber ich bin weder der Benutzer noch der dort zuständige Admin - ICH kann NICHTS auf die Zielkiste DAUERHAFT kopieren. Dann muß ich wie oben auch schon erwähnt, den Druck abbrechen, wenn diese Datei nicht mehr vorhanden ist oder verändert wurde (also auch noch hashen).

Natürlich kannst du dort nichts dauerhaft kopieren, auch nicht deine Anwendung. Aber das ist alles halb so wild, denn erstens kannst du eine unbedingt benötigte Font-Datei in einer Ressurce lagern, und zweitens haben Anwender ohne Admin-Status gewöhnlich keinen Zugriff auf die Programmordner, außer sie setzen noch Win XP ein. Wenn der Anwender deine Anwendung deinstallieren möchte, kannst du natürlich nichts dagegen unternehmen

Anwendungsfall: Ein Kunde hat sich Rechnungsvordrucke in einer Druckerei drucken lassen und möchte nun, daß seine Rechnungs-Anwendung genau denselben Font verwendet, um ein einheitliches Druckbild zu gewährleisten. Das funktioniert aber nur, wenn der Anwender den benötigten Font installiert hat – oder wenn ich die Fontdatei mitliefere und für die Dauer der Anwendungs-Sitzung genau diesen Font zur Verfügung stelle. Wenn der Anwender XP einsetzt, könnte er im Grunde die Fontdatei im Anwendungsordner löschen, was zwar eine blöde Idee wäre, aber es soll ja keinen DAU geben, den es nicht gibt. Also verwahre ich die Fontdatei in der Exe (eingebunden als Resource) und kopiere sie bei jedem Anwendungsstart in den Anwendungsordner, wenn sie fehlen sollte oder verändert wurde. Wo ist das Problem

Übrigens können Anwender, die mit Win XP arbeiten, auch leicht andere benötigte Dateien aus dem Programmordner löschen, z.B. DLLs wie z.B. bei einer Datenbankanwendung, die Firebird Embedded verwendet. Vielleicht löschen sie auch die Datenbank oder gar die Exe ("... ich hab halt kürzlich gelesen, daß Exe-Dateien gefährlich sind ..."), wer weiß das schon? Mit anderen Worten: Du kannst nicht alle Eventualitäten, die ein DAU herbeiführen könnte, berücksichtigen. Ein Bekannter von mir arbeitet bei einer Hotline, der könnte dir Geschichten erzählen, das glaubst du nicht ...

[Furtbichler]

Also:
1. Wenn es geht, den Barcodegenerator des Druckers verwenden (z.B. Zebra-Druckersprache)
2. Sonst einen guten Reportgenerator verwenden, der Barcodes anhand der Zieldruckerauflösung pixelgenau rendert.
3. Sonst nach einer Delphi-VCL Barcodekomponente suchen (Andreas Schmidt, siehe torry.net) und auf die Zieldruckerauflösung rendern.
4. Oder eben einen Font verwenden (nur für 'große' Barcodes mit einer minimalen Balkenbreite von 3-4pxl)

Auch, und bitte *immer* die Druckerqualität berücksichtigen, mein Tintendrucker z.B. druckt auf normalem Papier Barcodes aus, die zwar pixelgenau sind, aber wegen des Verlaufens der Tinte von keinem Scanner der Welt gelesen werden können. Na gut, Interleaved 2 aus 5 mit einem 6 stelligen Code über die Seitenbreite geht dann doch.

[Serienchiller]

@sx2008

danke dir! das ist genau das, nachdem ich gesucht habe!
noch ne noobie frage dazu:
barcodes können wohl GRUNDSÄTZLICH nur aus ziffern gebildet werden?

[Patito]

Zitat von Serienchiller:

barcodes können wohl GRUNDSÄTZLICH nur aus ziffern gebildet werden?

Das hängt vom BarcodeTyp ab. Im Code128 gibt es z.B. sogar die Möglichkeit innerhalb des Barcodes
zwischen Zahlen und Buchstaben-Codierung umzuschalten.

Noch etwas zur Barcode-Größe: Normalerweise hat ein Barcode-Typ noch Standards
für Mindestgröße, mimimale Abstände, ...
Wenn man den Standard nicht beachtet (und z.B. einfach irgendwelche Fonts skaliert)
ist es Glückssache welche Scanner das dann lesen können.

[Furtbichler]

Zitat von Patito:

Noch etwas zur Barcode-Größe: Normalerweise hat ein Barcode-Typ noch Standards
für Mindestgröße, mimimale Abstände, ...
Wenn man den Standard nicht beachtet (und z.B. einfach irgendwelche Fonts skaliert)
ist es Glückssache welche Scanner das dann lesen können.

Oder einfacher ausgedrückt: Jeder Standard definiert das Verhältnis zwischen dünnen und dicken Strichen und Abständen. Beim Code-39 wäre das 1:1.8 - 1:2.4, ein dünner Strich ist also in etwa halb so dünn wie ein dicker.

Wenn der Renderer nun den dünnen Strich mal 2 und mal 3 Pixel, und den dicken Strich dafür mal 4 und mal 5 Pixel breit macht, dann haben wir ein verhältnis von 2:4 = 1:2 bis 3:4 = 1:1.3 . Und das ist dann klar außerhalb der Spec. Kein Scanner (nun ja, fast keiner) wird das dann lesen können.

Daraus folgt:
1. Der Renderer darf nicht einfach skalierte Rechtecke zeichnen, sondern muss die Pixelbreiten einmalig berechnen und dann pixelgenau füllen.
2. Ein Barcode kann nicht beliebig breit sein, d.h. er lässt sich vertikal nur diskret vergrößern.