Wie macht man es einem OCR-Pogramm einfach?

[Marc Haber]

Hi.

ich möchte gerne vertrauliche Binärdaten (z.B. einen GPG-Key) als
Rückfallebene zur digitalen Kopie auf Papier aufbewahren.

QR-Codes möchte ich nicht verwenden weil der Umgang mit ihnen
kompliziert und unhandlich ist. Mir schwebt eher ein Prozess vor, bei
dem lesbarer Text ausgedruckt wird, den ich im Zweifel entweder
abtippen oder durch eine OCR-Software schicken kann.

Wie mache ich einer OCR-Software das Lesen eines eingescannten
Ausdrucks besonders einfach?

- Font. Etwas nichtproportionales wie Consoloas, oder etwas
proportionales wie Verdana? Natürlich muss man darauf achten, dass die
"üblichen Verdächtigen" wie Il, 0O sich hinreichend voneinander
unterscheiden, weil die OCR-Software bei dieser Art Daten nicht auf
ein Wörterbuch zurückgreifen kann.

- Größe. Etwas größer, 14 Punkt oder mehr, damit der Scanner nicht
perfekt sein muss.

- Einfache Fehlererkennung: eine Prüfsumme (z.b. die letzten fünf
Zeichen eines SHA-1-Hashes) pro Zeile. Zum Glück müssen wir hier nicht
von einem Angriff ausgehen, so dass wir provozierte Hashkollisionen
hier ignorieren können. Und natürlich eine Prüfsumme für das gesamte
file, z.b. ungekürztes SHA-1 oder -256.

- Encoding der Binärdaten. Hex oder base64?

Habt Ihr noch andere Vorschläge zu diesem Thema?

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Michael Bäuerle]

Marc Haber wrote:
>
> ich möchte gerne vertrauliche Binärdaten (z.B. einen GPG-Key) als
> Rückfallebene zur digitalen Kopie auf Papier aufbewahren.
>
> QR-Codes möchte ich nicht verwenden weil der Umgang mit ihnen
> kompliziert und unhandlich ist. Mir schwebt eher ein Prozess vor, bei
> dem lesbarer Text ausgedruckt wird, den ich im Zweifel entweder
> abtippen oder durch eine OCR-Software schicken kann.
>
> Wie mache ich einer OCR-Software das Lesen eines eingescannten
> Ausdrucks besonders einfach?
>
> - Font. Etwas nichtproportionales wie Consoloas, oder etwas
> proportionales wie Verdana? Natürlich muss man darauf achten, dass die
> "üblichen Verdächtigen" wie Il, 0O sich hinreichend voneinander
> unterscheiden, weil die OCR-Software bei dieser Art Daten nicht auf
> ein Wörterbuch zurückgreifen kann.

Es gibt ja seit allen Zeiten extra für diesen Zweck entwickelte Fonts
wie z.B. OCR-A [1].

Ich habe die zwar noch nie mit aktueller OCR-Software verwendet, aber
sowas würde ich als erstes testen. Es gibt laut WP ISO-, ANSI- und
DIN-Normen dafür, ich würde daher mal unterstellen, dass OCR-Software
das Layout dieser Zeichen kennt.

OCR-A sieht jetzt fürs menschliche Auge nicht so hübsch aus, aber
genau das ist dir ja für diesen Anwendungsfall egal.

Der konstante Zeichenabstand eines nichtproportionalen Fonts macht es
der OCR-Software vermutlich generell einfacher (die Pixel den richtigen
Zeichen zuzuordnen).

> - Größe. Etwas größer, 14 Punkt oder mehr, damit der Scanner nicht
> perfekt sein muss.

Groß genug, damit weder die Auflösung von Drucker noch Scanner die
Außenkontur der Zeichen nennenswert verändern.

> - Einfache Fehlererkennung: eine Prüfsumme (z.b. die letzten fünf
> Zeichen eines SHA-1-Hashes) pro Zeile. Zum Glück müssen wir hier nicht
> von einem Angriff ausgehen, so dass wir provozierte Hashkollisionen
> hier ignorieren können. Und natürlich eine Prüfsumme für das gesamte
> file, z.b. ungekürztes SHA-1 oder -256.

Ja, maschinell prüfen sollte sich das Ergebnis natürlich lassen.

> - Encoding der Binärdaten. Hex oder base64?

Base64 hätte den Vorteil, dass es weniger Platz verbraucht - wenn man es
doch mal händisch eintippen muss - und trotzdem nur gängige Zeichen ver-
wendet (und Zeilenumbrüche automatisch ignoriert). Das sollte auf jeden
Fall immer noch mit quasi jedem Font verwendbar sein.


___________________
[1] <https://en.wikipedia.org/wiki/OCR-A_font>

[Marc Haber]

Michael Bäuerle <michael....@stz-e.de> wrote:
>Marc Haber wrote:
>> ich möchte gerne vertrauliche Binärdaten (z.B. einen GPG-Key) als
>> Rückfallebene zur digitalen Kopie auf Papier aufbewahren.
>>
>> QR-Codes möchte ich nicht verwenden weil der Umgang mit ihnen
>> kompliziert und unhandlich ist. Mir schwebt eher ein Prozess vor, bei
>> dem lesbarer Text ausgedruckt wird, den ich im Zweifel entweder
>> abtippen oder durch eine OCR-Software schicken kann.
>>
>> Wie mache ich einer OCR-Software das Lesen eines eingescannten
>> Ausdrucks besonders einfach?
>>
>> - Font. Etwas nichtproportionales wie Consoloas, oder etwas
>> proportionales wie Verdana? Natürlich muss man darauf achten, dass die
>> "üblichen Verdächtigen" wie Il, 0O sich hinreichend voneinander
>> unterscheiden, weil die OCR-Software bei dieser Art Daten nicht auf
>> ein Wörterbuch zurückgreifen kann.
>
>Es gibt ja seit allen Zeiten extra für diesen Zweck entwickelte Fonts
>wie z.B. OCR-A [1].

Die wurden in den 1970ern für die damaligen Möglichkeiten entwickelt,
ja. Wir haben 2015 und haben heute die damaligen Möglichkeiten aller
Großforschungsinstitutionen der Welt zusammen in jedem Mobiltelefon
und jagen damit Pokemons.

Mir hat bisher noch niemand schlüssig darlegen können, das OCR-A heute
noch besser gelesen werden kann als z.B. Verdana.

>Ich habe die zwar noch nie mit aktueller OCR-Software verwendet, aber
>sowas würde ich als erstes testen. Es gibt laut WP ISO-, ANSI- und
>DIN-Normen dafür, ich würde daher mal unterstellen, dass OCR-Software
>das Layout dieser Zeichen kennt.

Wie willst du sowas "testen"?

>OCR-A sieht jetzt fürs menschliche Auge nicht so hübsch aus, aber
>genau das ist dir ja für diesen Anwendungsfall egal.
>
>Der konstante Zeichenabstand eines nichtproportionalen Fonts macht es
>der OCR-Software vermutlich generell einfacher (die Pixel den richtigen
>Zeichen zuzuordnen).

Genau das steht im Web in vielen Quellen anders ("nutze eine
Proportionalschrift, so sind Bücher gedruckt, in das Erkennen von
Proportionalschriten ist in den letzten 20 Jahren signifikant mehr
Gehirnschmalz geflossen als in das erkennen nicht proportionaler
Schriften").

>> - Größe. Etwas größer, 14 Punkt oder mehr, damit der Scanner nicht
>> perfekt sein muss.
>
>Groß genug, damit weder die Auflösung von Drucker noch Scanner die
>Außenkontur der Zeichen nennenswert verändern.

Das ist bei heutiger Technik ja wohl schon bei 7 Punkt gegeben.

>> - Einfache Fehlererkennung: eine Prüfsumme (z.b. die letzten fünf
>> Zeichen eines SHA-1-Hashes) pro Zeile. Zum Glück müssen wir hier nicht
>> von einem Angriff ausgehen, so dass wir provozierte Hashkollisionen
>> hier ignorieren können. Und natürlich eine Prüfsumme für das gesamte
>> file, z.b. ungekürztes SHA-1 oder -256.
>
>Ja, maschinell prüfen sollte sich das Ergebnis natürlich lassen.
>
>> - Encoding der Binärdaten. Hex oder base64?
>
>Base64 hätte den Vorteil, dass es weniger Platz verbraucht - wenn man es
>doch mal händisch eintippen muss - und trotzdem nur gängige Zeichen ver-
>wendet (und Zeilenumbrüche automatisch ignoriert). Das sollte auf jeden
>Fall immer noch mit quasi jedem Font verwendbar sein.

Wobei man bei Hex signifikant weniger genau hingucken muss. Gibt einen
Standard "base36", der nur aus den Ziffern und Kleinbuchstaben
besteht, damit man sich beim Eintippen nicht auch noch mit der
Shift-Taste verhakeln muss?

[Michael Bäuerle]

Marc Haber wrote:
> Michael Bäuerle <michael....@stz-e.de> wrote:
> > Marc Haber wrote:
> > >
> > Es gibt ja seit allen Zeiten extra für diesen Zweck entwickelte Fonts
> > wie z.B. OCR-A [1].
>
> Die wurden in den 1970ern für die damaligen Möglichkeiten entwickelt,
> ja. Wir haben 2015 und haben heute die damaligen Möglichkeiten aller
> Großforschungsinstitutionen der Welt zusammen in jedem Mobiltelefon
> und jagen damit Pokemons.
>
> Mir hat bisher noch niemand schlüssig darlegen können, das OCR-A heute
> noch besser gelesen werden kann als z.B. Verdana.

Damals in den 70er Jahren wird man wohl einfach jeden Buchstaben einzeln
isoliert und analysiert haben.

Mein Erklärungsversuch wäre:
Die heutige OCR-Software nutzt die vorhandenen Ressourcen vor allem
um besser raten zu können, wenn etwas unklar ist. Zum Beispiel in dem
sie den Kontext mit einbezieht (Unser Gehirn versucht ja auch ganze
Wörter als Bilder zu interpretieren).
Das funktioniert aber vmtl. nur mit bestimmtem Text, auf den sie aus-
gelegt ist, besonders gut. Ob Zahlenkolonnen oder Base64-Daten ohne
"Wörter" da dazugehören, möchte ich eher anzweifeln.

Wenn es durch einen geeigneten Font aber gar nicht nötig ist zu raten,
dann werden diese Fähigkeiten nicht benötigt (oder haben mehr Marge).

Ungeeignete Fonts zu verwenden und die schlechte Lesbarkeit dann mit
Rechenleistung zu kompensieren wäre allerdings in der Tat der
"modernere" Lösungsansatz.
Du hattest aber explizit gefragt, wie man es der OCR-Software möglichst
einfach machen kann, nicht wie man ihre Fähigkeiten bis zum Limit
ausreizt weil CPU-Power brach liegt.

> > Ich habe die zwar noch nie mit aktueller OCR-Software verwendet, aber
> > sowas würde ich als erstes testen. Es gibt laut WP ISO-, ANSI- und
> > DIN-Normen dafür, ich würde daher mal unterstellen, dass OCR-Software
> > das Layout dieser Zeichen kennt.
>
> Wie willst du sowas "testen"?

Mit Testdaten füttern und die Ergebnisse prüfen.

Die gleichen Testdaten mit verschiedenen Fonts absichtlich zu klein
ausdrucken oder anderweitig die Lesbarkeit verschlechtern (farbiges
Papier um den Kontrast zu verschlechtern, Kaffee drüberkippen, Papier
zerknüllen und dann in nur grob glattgestrichenem Zustand scannen, etc.)

> > OCR-A sieht jetzt fürs menschliche Auge nicht so hübsch aus, aber
> > genau das ist dir ja für diesen Anwendungsfall egal.
> >
> > Der konstante Zeichenabstand eines nichtproportionalen Fonts macht es
> > der OCR-Software vermutlich generell einfacher (die Pixel den richtigen
> > Zeichen zuzuordnen).
>
> Genau das steht im Web in vielen Quellen anders ("nutze eine
> Proportionalschrift, so sind Bücher gedruckt, in das Erkennen von
> Proportionalschriten ist in den letzten 20 Jahren signifikant mehr
> Gehirnschmalz geflossen als in das erkennen nicht proportionaler
> Schriften").

Trotzdem dürfte der Vorsprung durch solchen Gehirnschmalz immer dann
besonders groß sein, wenn etwas nicht klar erkennbar ist. Und es hängt
wohl stark von der verwendeten Software ab, was sie dann als Kontext
bevorzugt (bzw. überhaupt als Kontext nutzen kann).
Dass da dann jede Software immer und mit jedem proportionalen Font
besser ist glaube ich nicht.

Von einem Font mit geeigneten, möglichst unterschiedlichen Glyphen und
guter Erkennbarkeit durch ausreichende Schriftgröße dürften dagegen jede
OCR-Software profitieren, selbst solche völlig ohne Gehirnschmalz.

Du hattest auch keine konkrete OCR-Software genannt.

> > > - Größe. Etwas größer, 14 Punkt oder mehr, damit der Scanner nicht
> > > perfekt sein muss.
> >
> > Groß genug, damit weder die Auflösung von Drucker noch Scanner die
> > Außenkontur der Zeichen nennenswert verändern.
>
> Das ist bei heutiger Technik ja wohl schon bei 7 Punkt gegeben.

Hängt auch davon ab wie sorgfältig du den Ausdruck behandeln möchtest.
Wenn der dann im Tresor liegt und tatsächlich niemals eine Falte oder
einen Fleck bekommt.

> > > - Einfache Fehlererkennung: eine Prüfsumme (z.b. die letzten fünf
> > > Zeichen eines SHA-1-Hashes) pro Zeile. Zum Glück müssen wir hier nicht
> > > von einem Angriff ausgehen, so dass wir provozierte Hashkollisionen
> > > hier ignorieren können. Und natürlich eine Prüfsumme für das gesamte
> > > file, z.b. ungekürztes SHA-1 oder -256.
> >
> > Ja, maschinell prüfen sollte sich das Ergebnis natürlich lassen.
> >
> > > - Encoding der Binärdaten. Hex oder base64?
> >
> > Base64 hätte den Vorteil, dass es weniger Platz verbraucht - wenn man es
> > doch mal händisch eintippen muss - und trotzdem nur gängige Zeichen ver-
> > wendet (und Zeilenumbrüche automatisch ignoriert). Das sollte auf jeden
> > Fall immer noch mit quasi jedem Font verwendbar sein.
>
> Wobei man bei Hex signifikant weniger genau hingucken muss. Gibt einen
> Standard "base36", der nur aus den Ziffern und Kleinbuchstaben
> besteht, damit man sich beim Eintippen nicht auch noch mit der
> Shift-Taste verhakeln muss?

Das dürfte wieder stark vom Font abhängen. Wenn z.B. 1/l oder 0/O sich
besonders wenig unterscheiden, dann sollte Hex direkt (weder l noch O)
einen Vorteil gegenüber den Codierungen haben, die diese Buchstaben ver-
wenden.

Mit einem Font wie OCR-A sollte das nicht der Fall sein, und dann ist
die höhere Datenmenge wohl eher schädlich (mehr Zeichen => mehr
Möglichkeiten eines davon falsch zu erkennen).

Und wirklich abtippen willst du das ja nicht, das soll nur ein
Notnagel sein wenn ich dich richtig verstanden habe. Dann würde ich
das System auch nicht dafür auslegen, dass dieser Fall möglichst
komfortabel ist.

[Florian Weimer]

* Marc Haber:

> QR-Codes möchte ich nicht verwenden weil der Umgang mit ihnen
> kompliziert und unhandlich ist.

Was stört Dich an zbarimg -q? Daß dort das base64 nicht 1:1
herausfällt, sondern ein QR-Code:-Präfix dabei ist?

[Marc Haber]

Michael Bäuerle <michael....@gmx.net> wrote:
>Marc Haber wrote:
>> Michael Bäuerle <michael....@stz-e.de> wrote:
>> > Marc Haber wrote:
>> > >
>> > Es gibt ja seit allen Zeiten extra für diesen Zweck entwickelte Fonts
>> > wie z.B. OCR-A [1].
>>
>> Die wurden in den 1970ern für die damaligen Möglichkeiten entwickelt,
>> ja. Wir haben 2015 und haben heute die damaligen Möglichkeiten aller
>> Großforschungsinstitutionen der Welt zusammen in jedem Mobiltelefon
>> und jagen damit Pokemons.
>>
>> Mir hat bisher noch niemand schlüssig darlegen können, das OCR-A heute
>> noch besser gelesen werden kann als z.B. Verdana.
>
>Damals in den 70er Jahren wird man wohl einfach jeden Buchstaben einzeln
>isoliert und analysiert haben.

Heute wird man bei der gegebenen Anforderung vermutlich auch auf
diesen Weg zurückfallen müssen.

>Mein Erklärungsversuch wäre:
>Die heutige OCR-Software nutzt die vorhandenen Ressourcen vor allem
>um besser raten zu können, wenn etwas unklar ist. Zum Beispiel in dem
>sie den Kontext mit einbezieht (Unser Gehirn versucht ja auch ganze
>Wörter als Bilder zu interpretieren).
>Das funktioniert aber vmtl. nur mit bestimmtem Text, auf den sie aus-
>gelegt ist, besonders gut. Ob Zahlenkolonnen oder Base64-Daten ohne
>"Wörter" da dazugehören, möchte ich eher anzweifeln.

Da hast Du freilich recht.

>Wenn es durch einen geeigneten Font aber gar nicht nötig ist zu raten,
>dann werden diese Fähigkeiten nicht benötigt (oder haben mehr Marge).

Richtig. Was hältst Du in diesem Kontext von OCR-B?

>Ungeeignete Fonts zu verwenden und die schlechte Lesbarkeit dann mit
>Rechenleistung zu kompensieren wäre allerdings in der Tat der
>"modernere" Lösungsansatz.
>Du hattest aber explizit gefragt, wie man es der OCR-Software möglichst
>einfach machen kann, nicht wie man ihre Fähigkeiten bis zum Limit
>ausreizt weil CPU-Power brach liegt.

Die Frage ist halt, ob heutige Software mit so "künstlichen" Fonts wie
OCR-A überhaupt klar kommt bzw ob sie jemals mit sowas getestet wurde.

>> > Ich habe die zwar noch nie mit aktueller OCR-Software verwendet, aber
>> > sowas würde ich als erstes testen. Es gibt laut WP ISO-, ANSI- und
>> > DIN-Normen dafür, ich würde daher mal unterstellen, dass OCR-Software
>> > das Layout dieser Zeichen kennt.
>>
>> Wie willst du sowas "testen"?
>
>Mit Testdaten füttern und die Ergebnisse prüfen.

Das geht aber bestenfalls als Stichprobe durch. Ich habe leider nicht
die Zeit, darüber zu promovieren.

>Die gleichen Testdaten mit verschiedenen Fonts absichtlich zu klein
>ausdrucken oder anderweitig die Lesbarkeit verschlechtern (farbiges
>Papier um den Kontrast zu verschlechtern, Kaffee drüberkippen, Papier
>zerknüllen und dann in nur grob glattgestrichenem Zustand scannen, etc.)

das könnt man in der Tat probieren, wobei ich erwarte, dass man mit
diesen Vorlagen sorgfältig umgehen wird. Sie werden die meiste Zeit eh
im Bankschließfach liegen.

>Du hattest auch keine konkrete OCR-Software genannt.

Das liegt dran dass ich nicht weiß welche Software man vielleicht in
20 Jahren verwenden wird, um das wieder einzulesen. Ich werde meine
Tests vermutlich mit tesseract machen; die Wahrscheinlichkeit ist hoch
dass man dessen Sourcen auch in 20 Jahren noch kompiliert bekommt.

>> > > - Größe. Etwas größer, 14 Punkt oder mehr, damit der Scanner nicht
>> > > perfekt sein muss.
>> >
>> > Groß genug, damit weder die Auflösung von Drucker noch Scanner die
>> > Außenkontur der Zeichen nennenswert verändern.
>>
>> Das ist bei heutiger Technik ja wohl schon bei 7 Punkt gegeben.
>
>Hängt auch davon ab wie sorgfältig du den Ausdruck behandeln möchtest.

Sehr. Sorgfältig.

>> > Base64 hätte den Vorteil, dass es weniger Platz verbraucht - wenn man es
>> > doch mal händisch eintippen muss - und trotzdem nur gängige Zeichen ver-
>> > wendet (und Zeilenumbrüche automatisch ignoriert). Das sollte auf jeden
>> > Fall immer noch mit quasi jedem Font verwendbar sein.
>>
>> Wobei man bei Hex signifikant weniger genau hingucken muss. Gibt einen
>> Standard "base36", der nur aus den Ziffern und Kleinbuchstaben
>> besteht, damit man sich beim Eintippen nicht auch noch mit der
>> Shift-Taste verhakeln muss?
>
>Das dürfte wieder stark vom Font abhängen. Wenn z.B. 1/l oder 0/O sich
>besonders wenig unterscheiden, dann sollte Hex direkt (weder l noch O)
>einen Vorteil gegenüber den Codierungen haben, die diese Buchstaben ver-
>wenden.

Schade dass es offensichtlich keine Codierung gibt, die leicht
verwechselbare Zeichen einfach weglässt.

>Mit einem Font wie OCR-A sollte das nicht der Fall sein, und dann ist
>die höhere Datenmenge wohl eher schädlich (mehr Zeichen => mehr
>Möglichkeiten eines davon falsch zu erkennen).
>
>Und wirklich abtippen willst du das ja nicht, das soll nur ein
>Notnagel sein wenn ich dich richtig verstanden habe. Dann würde ich
>das System auch nicht dafür auslegen, dass dieser Fall möglichst
>komfortabel ist.

Komfortabel nicht, aber möglich.

[Marc Haber]

Alleine das Erzeugen des Ausdrucks möglichst so, dass keine temporären
Dateien irgendwo hingeworfen werden, scheint mir erheblich
komplizierter. Aber das mag Verblendung sein.

[Michael Bäuerle]

Marc Haber wrote:
> Michael Bäuerle <michael....@gmx.net> wrote:
> >
> > [...]

> > Mein Erklärungsversuch wäre:
> > Die heutige OCR-Software nutzt die vorhandenen Ressourcen vor allem
> > um besser raten zu können, wenn etwas unklar ist. Zum Beispiel in dem
> > sie den Kontext mit einbezieht (Unser Gehirn versucht ja auch ganze
> > Wörter als Bilder zu interpretieren).
> > Das funktioniert aber vmtl. nur mit bestimmtem Text, auf den sie aus-
> > gelegt ist, besonders gut. Ob Zahlenkolonnen oder Base64-Daten ohne
> > "Wörter" da dazugehören, möchte ich eher anzweifeln.
>
> Da hast Du freilich recht.
>
> > Wenn es durch einen geeigneten Font aber gar nicht nötig ist zu raten,
> > dann werden diese Fähigkeiten nicht benötigt (oder haben mehr Marge).
>
> Richtig. Was hältst Du in diesem Kontext von OCR-B?

Da die OCR-B ja mehr für das menschliche Auge entworfen wurde als OCR-A,
dürfte sie weniger Sicherheitsmarge bei der Erkennung bieten. Wenn ich
mir die Glyphen so anschaue, dann liegt die Schwachstelle IMHO bei O/0.
Diese beiden Glyphen sehen dort deutlich weniger verschieden aus als bei
OCR-A.

> > Ungeeignete Fonts zu verwenden und die schlechte Lesbarkeit dann mit
> > Rechenleistung zu kompensieren wäre allerdings in der Tat der
> > "modernere" Lösungsansatz.
> > Du hattest aber explizit gefragt, wie man es der OCR-Software möglichst
> > einfach machen kann, nicht wie man ihre Fähigkeiten bis zum Limit
> > ausreizt weil CPU-Power brach liegt.
>
> Die Frage ist halt, ob heutige Software mit so "künstlichen" Fonts wie
> OCR-A überhaupt klar kommt bzw ob sie jemals mit sowas getestet wurde.

Ja. Wenn das nicht der Fall ist, könnte das Ergebnis auch grotten-
schlecht sein (wegen des "ungewöhnlichen" Aussehens von OCR-A).
Da dieser Font aber offiziell genormt wurde, darf man wohl schon davon
ausgehen, dass OCR-Software ihn kennt ...

Gerade mal einen Verrechnungsscheck-Vordruck meiner Bank herausgezogen:
Für die Beschriftung wurde OCR-A verwendet. Das wird also nach über 40
Jahren auch wirklich noch verwendet. Es kann dafür doch eigentlich nur
zwei Gründe geben: Es wurde seither kein besserer Font erfunden oder
die Software-Unterstützung für OCR-A ist besonders gut.

BTW:
Es wäre schön, wenn du die Ergebnisse deiner Tests hier posten könntest.
Das dürfte sicher noch mehr Leute interessieren.

[Marc Haber]

Michael Bäuerle <michael....@gmx.net> wrote:
>Marc Haber wrote:

>> Richtig. Was hältst Du in diesem Kontext von OCR-B?
>
>Da die OCR-B ja mehr für das menschliche Auge entworfen wurde als OCR-A,
>dürfte sie weniger Sicherheitsmarge bei der Erkennung bieten.

Ist sie nicht auch unter Hinblick auf die leistungsfähigere Hardware
entworfen worden?

>> Die Frage ist halt, ob heutige Software mit so "künstlichen" Fonts wie
>> OCR-A überhaupt klar kommt bzw ob sie jemals mit sowas getestet wurde.
>
>Ja. Wenn das nicht der Fall ist, könnte das Ergebnis auch grotten-
>schlecht sein (wegen des "ungewöhnlichen" Aussehens von OCR-A).
>Da dieser Font aber offiziell genormt wurde, darf man wohl schon davon
>ausgehen, dass OCR-Software ihn kennt ...

Könnte man versuchen.

>Gerade mal einen Verrechnungsscheck-Vordruck meiner Bank herausgezogen:
>Für die Beschriftung wurde OCR-A verwendet. Das wird also nach über 40
>Jahren auch wirklich noch verwendet. Es kann dafür doch eigentlich nur
>zwei Gründe geben: Es wurde seither kein besserer Font erfunden oder
>die Software-Unterstützung für OCR-A ist besonders gut.

Oder der Standard ist so fest gemeißelt dass sich da niemand ran
traut.

>BTW:
>Es wäre schön, wenn du die Ergebnisse deiner Tests hier posten könntest.
>Das dürfte sicher noch mehr Leute interessieren.

Werde ich tun.

[Michael Bäuerle]

Marc Haber wrote:
> Michael Bäuerle <michael....@gmx.net> wrote:
> > Marc Haber wrote:
> > >

> > > [...] Was hältst Du in diesem Kontext von OCR-B?

> >
> > Da die OCR-B ja mehr für das menschliche Auge entworfen wurde als OCR-A,
> > dürfte sie weniger Sicherheitsmarge bei der Erkennung bieten.
>
> Ist sie nicht auch unter Hinblick auf die leistungsfähigere Hardware
> entworfen worden?

Wenn man Wikipedia glauben darf, hat sie A. Frutiger schon im gleichen
Jahr 1968 entworfen. Die Normung war wohl unterschiedlich und hat auch
viele Jahre gedauert (OCR-B sei seit 1973 eine ISO Norm).

Frutiger war Schweizer, OCR-A stammt dagegen von den Amerikanern.
Da könnte also immer auch ein gehöriger Teil NIH mitgespielt haben.