AutoOCR – neue Version 1.10.4

Mit der AutoOCR Version 1.10.4 wurden Erweiterungen im Bereich der Job Funktionen für die Web-Service Schnittstelle implementiert.

Neue Job-Funktionen:

  • Alle Jobs am Server löschen
  • Filter für Datum – Erzeugt / Konvertiert – von / bis
  • Filter für Username und Label mit Wildcard Suche (*)
  • Funktion zum Blättern der Seiten in der Ergebnisliste mit Angabe der Treffer pro Seite – die Job Liste kann seitenorientiert abgerufen und geblättert werden.
  • Sortierung der abgerufenen Liste nach – Erzeugungsdatum, Konvertierungsdatum, Status, Username, Job-Label – auf bzw. absteigend.

Das über ein getrenntes Setup installierbare .NET Beispielprogramm –  zeigt alle diese neuen Funktionen bzw. ermöglicht deren Test.

AutoOCR_jobfiltering Signatur der neuen Job Funktionen - AutoOCR 1.10.4

Signatur der neuen Job Funktionen – AutoOCR 1.10.4

Download – AutoOCR – OCR Server inkl. iOCR Engine (ca. 150MB) >>>
Download – AutoOCR – Web-Service Beispiel-Client  inkl. C# Source >>>

Für die Abbyy OCR Engine Version 10 stehen Demolizenzen für 30 Tage bzw. 500 Seiten zur Verfügung – diese können Sie gerne bei uns anfordern

Download- Abbyy FineReader 10.x Rel 4 OCR Engine Setup (ca. 460MB) >>>
Demolizenzkey für FineReader OCR Engine anfordern

ifresco AutoOCR – Version 1.14

  • FEATURE: Kombatibilität für Alfresco 4.2.bCE mit Java7
  • FEATURE: “Über AutoOCR” Reiter in der Admin Konsole mit Angaben zur installierten Version
  • FIX: Replace target Dokument switch bei gleichem Mimetype wie das orginal wurde nicht ausgewertet.

Der ifresco AutoOCR Transformer – ist somit für folgende Alfresco Versionen als installierbares AMP verfügbar:

  • Alfresco CE 4.0d, 4.2b
  • Alfresco EE 4.0.0, 4.0.1, 4.0.2, 4.1.1

iPaper – Neue Version 2.1.35

Die neue iPaper Version 2.1.35 verfügt über eine Reihe von neue Funktionen und Möglichkeiten:

Vorlagen mit alternativer Ausrichtung

Es gibt immer wieder Anwendungsfälle bei dem in einem Dokument – Hoch und Querformate gemischt vorhanden sind – MS-Word bietet z.b. die Möglichkeit die Orientierung im Dokument Seite für Seite umzuschalten – bisher wurden solche gemischten Formate von iPaper nicht unterstützt – es war nur möglich Seiten mit alternativen Formaten – auszulassen und nicht zu verarbeiten. Ebenso musste man sich bisher je nach Ausrichtung 2 Vorlagen definieren und diese je nach Orientierung vor dem Ausdruck händisch auswählen.

Das ist jetzt wesentlich einfacher und eleganter gelöst – man kann jetzt zu jeder Vorlage ein PDF für die  “Alternative Ausrichtung” festlegen – also wenn die Vorlage ein Hochformat A4 ist – alternativ dazu ein Querformat A4 oder umgekehrt.

iPaper erkennt dann selbsttätig, Seite für Seite welche der beiden Vorlagen passt und verwendet diese dann für das Over / Underlay. Sie müssen sich also keine Gedanken diesbezüglich mehr machen mit welcher Ausrichtung Sie ausgeben und welches Formular dafür passen könnte.

Briefpapier mit alternativer Ausrichtung

Check – PDF Rotate für das ausgewählte Formular

Das PDF Format verfügt über die Möglichkeit im Dokument einen  “Display Rotate” Parameter anzugeben – z.b. 0 / 90 / 180 / 270. Beim Aufruf über einen PDF Reader wird dieser Parameter ausgelesen und die Anzeigen wird entsprechend dem Parameter automatisch gedreht angezeigt. Davon bekommt der Anwender nichts mit – das PDF wurde zwar gedreht erzeugt – wird jedoch im Reader immer korrekt angezeigt. Verwendet man jetzt ein solches PDF als iPaper Briefpapier – wird die PDF-Vorlage in der Voransicht zwar richtig angezeigt – bei der Verarbeitung passt jedoch das Format der Druckausgabe und das Formular dann nicht  mehr zusammen und es kommt zu einem unerwarteten Ergebnis.

Aus diesem Grund haben wir einen Check eingebaut. Bei der Auswahl einer Vorlage muss die Farbe des Textlabels “Grün” sein – ist diese “Rot” – so hat das ausgewählte PDF einen “Display Rotate” Parameter ungleich “0” und sollte daher nicht verwendet werden.

Check - PDF display rotation parameter

Neuen Anfang in Mehrseiten Dokumenten erkennen

Es gibt Anwendungsfälle da kann es erforderlich sein in einem mehrseitigen Dokument den Beginn neuer Einzeldokumente automatisch zu erkennen. z.b. erstellt man unter MS-Word einen Serienbrief – so bekommt man als Ergebnis eine Gesamtdatei – die alle Einzel-Dokumente nun in einem enthält. iPaper hat eine Funktion um auf Folgeseiten ein anderes Formular anzuwenden – das würde in so einem Falls dann nicht mehr richtig funktionieren. Hier ist es erforderlich im  Gesamtdokument den Beginn der Einzeldokumente zu erkennen und danach dann das Briefpapier aufzubringen – in der richtigen Folge mit erster Seite und Folgeseiten.

Dafür gibt es jetzt einen Funktion um den Beginn eines neuen Dokuments automatisch erkennen zu können. Es wird ein Suchstring definiert – wird dieser gefunden so wird die Seite automatisch wie der Beginn eines neuen Dokuments behandelt.

Neuen Dokumentenanfang erkennen

Neue Beispiel – Briefpapiere werden installiert

Die bisher mit iPaper automatisch mit installierten Beispiel Briefpapiere wurde durch neue moderner gestaltete Beispiele ersetzt. 5 verschiedene Beispiele werden installiert. Alle Vorlagen verfügen auch über eine 2. Seite womit die iPaper Funktion für Folgeseiten direkt getestet werden kann.

Muster1 Muster2 muster3 muster4 muster5

Download – iPaper Musterbriefpapiere >>>

Neue einfache Möglichkeit der Parameterübergabe für die XML Steuerung

Die Steuerung der Weiterverarbeitung kann über XML Steuerkommandos erfolgen – die Übergabe der kompletten und fertigen XML Steuer-Kommandos erfolgte bisher entweder über die Druckausgabe d.h. die XML – Kommandos wurden mitgedruckt oder aber die XML Datei wurde extern zur Verfügung gestellt. Oft stellt jedoch die valide Erzeugung einer kompletten XML Datei ein Problem dar – speziell wenn die Steuerung über die Druckausgabe erfolgen soll. Bis jetzt musste immer die komplette Information mit übergeben werden.

Es gibt jetzt eine einfachere und schlankere Möglichkeit – Die XML wird mit Variablen versehen und bleibt extern. In der Druckausgabe werden nur mehr die Variablen und deren Werte ausgegeben. Diese Information wird bei der Druckausgabe erkannt, extrahiert und in die XML eingefügt. Die daraus entstandene XML Steuerdatei wird dann für die Steuerung der Weiterverarbeitung verwendet.

Beispiel:

@@BEGIN_VAR@@
@@VAR1{Dateiname_MAY12345}@@
@@VAR2{wmay@may.co.at}@@
@@END_VAR@@

Verwendung von Variablen für Dateiname und Email Adresse

Download – Beispiel – Verwendung von Variablen in der XML Steuerdatei >>>

Verwendung unterschiedlicher XML Templates und deren Auswahl

Bisher war es nur möglich eine einzige externe XML Templatevorlage zu konfigurieren und verwenden. Wollte man unterschiedliche Verarbeitungen anstoßen so ist dies bisher nur über die komplette im Ausdruck eingebettete XML Steuerinformation möglich gewesen.

Durch die neue Möglichkeit der Verwendung von Variablen war der logisch nächste Schritt die Möglichkeit zu eröffnen unterschiedliche externe XML Templates zu hinterlegen und diese dann wie bei den Variablen während des Druckvorgangs auszuwählen.

Es gibt nun 2 Möglichkeiten – über die ursprüngliche XML Definition und über die vereinfachte Definition:

Vereinfachte Definition:

@@BEGIN_VAR@@
@@BATCH_FILE{c:\\temp\\template.xml}@@
@@END_VAR@@

XML Definition:

XML Definiton welches Template verwendet werden soll

Zusätzlichen Druckertreiber nicht installieren

Beim Setup gibt es eine Option um einen zusätzlichen iPaper Druckertreiber “mit Rand” zu installieren. Es gibt Anwendungen die keine Ränder erzeugen und ausgeben können – dieser zusätzliche Treiber ermöglicht dies. Jedoch wird dieser oft nicht benötigt uns “verwirrt” die Anwender. Es gibt daher jetzt auch eine Option diesen nicht zu installieren.

msiexec /i iPaperNET.msi INST2NDPD=0 /quiet

Download – iPaper  32bit Version >>>
Download – iPaper  64bit Version >>>

MakePDFA.NET – Version 1.0.25 verfügbar

Die neue Version unterstützt jetzt auch Abbyy FineReader OCR in der Version 10 sowie iOCR als alternaive OCR Engine zu Abbyy. Mit enthalten ist jetzt auch eine COM / Active-X Komponente inkl. VB6 Beispielprogramm. Ebenfalls wurde eine Option richtiggestellt die bei interaktiver Verwendung wichtig ist.  Aktuell geöffnente Dokumente werden nicht mehr automatisch geschlossen wodurch eine Dokumentenkonvertierung über MS-Office im Hintergrund auch während der einer laufenden Dokumentenbearbeitung möglich wird.

Download Demo – MakePDFA.NET >>>

iPaper – benötigt für die Steuerung ein valides XML

iPaper bietet die Möglichkeit Voreinstellungen über XML Befehle dynamisch während der Programmausführung zu überschreiben und für die aktuelle Verarbeitung entsprechend zu ändern. Das XML kann entweder als externe Datei über einen vorkonfigurierten Pfad & Namen zur Verfügung gestellt – oder es kann im Ausdruck mit ausgedruckt und aus den Druckdaten extrahiert werdern.

Was in dem Zusammenhang wichtig ist und oft “falsch” gemacht wird – Ein XML sollte nicht per “Hand” erzeugt werden. Das birgt die mögliche  Gefahr dass das XML optisch zwar korret erscheint – jedoch nicht korrekt verarbeitet werden kann. z.b. weil die Kodierung nicht korrekt ist und z.b. eine Mischung aus UNICODE und “deutscher” Kodierung  verwendet wird.

Jedenfalls sollte für die Erzeugung und Bearbeitung von XML Dateien die von Microsoft verfügbare XML Komponente verwendet werden um die XML zu erzeugen. “Händisch” erzeugte XML bergen viele potentielle Fehlermöglichkeiten speziell was die Codierung der Zeichen betrifft. Die Microsoft XML Komponenten ermöglicht es valide XML Dokumente zu Erzeugen, zu Speichern und zu Laden. Beim Speichern über die MS-XML Komponente wird jedenfalls die richtige Kodierung sichergestellt.

Code Beispiel um ein XML mit der MS-XML Komponenten zu laden und zu speichern:

XML speichern & laden über MS-XML

Abbyy FineReader Seitenlizenzen – wie werden diese berechnet

Die meisten Anwender unserer OCR Produkte verwenden die Abbyy OCR Engine zusammen mit einer seitenbasierende Lizenz bei der ein bestimmtes Kontingent an Seiten pro Monat zur Verfügung steht.

Abbyy berechnte dabei die Seiten nach folgendem Schema:

Berechnung der Fläche einer verarbeiteten Seite:

Seitenbreite (in Pixel)                                      Seitenhöhe (in Pixel)

—————————–  *  2,54 (cm/inch) * —————————– * 2,54 (cm/inch)

Auflösung (in dpi)                                             Auflösung  (in dpi)

Division der Seitenfläche durch die Fläche einer A4 Seite

  • 21 cm * 29,7 cm = 623,7 cm*cm

Gezählte Seitenzahl ergibt sich:

  • = 1, wenn Seite kleiner als A4
  • = ganzzahliger Anteil vom Ergebnis aus der Division, wenn Seite größer als A4 ist

Bemerkung: Seitengröße (in Pixel) und Auflösung (in dpi) werden normalerweise von der Scannersoftware in den Bildeigenschaften im richtigen Verhältnis hinterlegt.  Bei inkorrekter Funktion der Scannersoftware kann es aber zu „problematischen“ Werten kommen, die dann eine Berechnung eines Vielfachen der eigentlichen Seitenzahl zur Folge haben.

Beispiel: Gescannte A4 Seite normal: ca. 2500 Pixel * 3500 Pixel bei 300 dpi. Falls durch eine Fehlfunktion die Auflösung auf 100 dpi gesetzt wurde, aber die Pixelgröße erhalten bleibt, wird die neunfache (3*3) Seitengröße gezählt.