Technical FAQs

When the time comes to extract data from standard forms, simply scanning the entire document isn’t an ideal solution. This is especially true of forms that include instructional text, since you probably don’t want to keep capturing “Directions” from every form. Even when looking only at fillable information, there can be a lot of text to capture. Optical character recognition makes it simple to automate data extraction as part of a forms processing workflow, but the most effective frameworks utilize a specialized form of recognition known as zonal OCR. 

What Is Zonal OCR?

While zonal OCR still identifies machine-printed text and matches it to existing character sets before handing it off to another stage of a predetermined workflow, what sets the process apart is the way it goes about reading a document page. A typical standard form often features multiple fillable boxes where someone can enter their information. It could also include drop-down menus with predetermined responses (suffix, state, and country are all common examples of this). Trying to recognize all of that text at once greatly increases the number of possible results, which could impact both accuracy and performance.

Zonal OCR addresses this challenge by splitting the page up into several distinct zones, each of which typically corresponds to a form field (although it doesn’t have to). Instead of reading the entire page, then, the OCR engine selectively recognizes the text in these zones. It can also be combined with form image dropout, which removes text and graphical elements that don’t need to be read and might interfere with the recognition process. By reducing the amount of text that needs to be matched, zonal OCR and significantly improve recognition speed and accuracy.

Limiting Recognition Results

The most effective OCR solutions then go a step further by designating the type of information that should be found within those zones. This reduces the range of potential outcomes, which makes it easier for the OCR engine to return an accurate reading.

For example, the letter “Z” bears superficial similarities to the number “2.” If the OCR engine needs to take into account all possible responses, it may struggle to distinguish between the two accurately, especially if an unusual font was used to complete the form. However, if developers stipulate that a particular “zone” should only include numerical values, the OCR engine suddenly goes from having to consider dozens of letters and special characters to just ten numbers. This makes it much easier to obtain an accurate recognition result.

For hand-printed form responses, applying the same zonal strategy to Intelligent Character Recognition (ICR) is especially helpful. Going back to the “Z” and “2” example, the distinctions between the two characters are often much more subtle in the case of hand-printing. If a form field includes the date to be printed out in a month/day/year format, there is no reason to include a “Z” in the list of potential characters that might be found in that field because no month includes a “Z.” When the ICR engine comes across a “2,” then, it’s more likely to identify it correctly because there are fewer potential alternative characters.

By constraining possible recognition results over a smaller range of defined character sets, zonal OCR and ICR both greatly improve accuracy when it comes to forms processing. The list of potential results is typically referred to as a data validation list.

In addition to constraining character sets, regular expressions can also be applied to different zones to specify what kind of data is expected to be found there. A regular expression is simply a string pattern that sets rules for how characters are formatted, such as a phone number, Social Security number, or credit card number.

Setting Up Zonal OCR

Integrating zonal OCR capabilities into a forms processing workflow first requires the creation of specialized templates that map out the location of each field that contains data. In any organization, the various types of standard forms received should always be built as templates within the solution. This allows the application to both match incoming forms to existing templates, but also align them to ensure that everything is in the proper location. 

The alignment step is extremely important for effective data extraction. Zonal OCR is set up to read only specific areas on a document page. These zones have clear boundaries, and anything caught outside that boundary will not be read while any character that’s only partly within the field will likely return an error result of some kind.

Accusoft’s SmartZone OCR/ICR integration, for instance, works most effectively when paired with the FormFix SDK, which handles form template creation, identification, and alignment. As part of the broader FormSuite solution, these integrations are extremely effective when it comes to streamlining data capture.

Improve Data Capture Accuracy with SmartZone

With OCR and ICR support for multiple languages, SmartZone is a powerful data extraction tool that can be incorporated into an application individually or with the rest of the FormSuite collection. It provides fast, accurate text recognition on both a zonal and a full-page basis. Developers can set up expected character patterns for fields and designate different regular expressions for all of them to deliver results that are significantly more accurate.

SmartZone not only provides out-of-the box support for pre-defined character sets, such as upper and lower case characters, arithmetic symbols, and currency symbols, it also allows developers to edit those sets to improve accuracy, confidence, and speed.

Find out how the SmartZone OCR/ICR can enhance your application’s forms processing data extraction today by downloading a free trial.

If your development team is building a data-rich application which will ingest gigabytes of data from newly-converted forms and born-digital ones, a cloud-based forms automation API can minimize development cost and effort. These days, forms are increasingly populated on mobile devices like smartphones and tablets as opposed to desktop browsers. 

Imagine if your clients, patients, employees, or constituents could fill out structured paper forms, then scan and submit them for processing. FormSuite in the Cloud helps your business reap the benefits of:

1. Hassle-free scanning followed by image capture and cleanup. 
2. Seamless identification of multiple form types.
3. Fast, accurate extraction of handwritten and typed data inputs. 

Custom development of this sort of functionality into your business application can add significant scope to the initial build and help you bypass those manual, incremental upgrades. Even if you are already experiencing the benefits of the Accusoft server-based FormSuite for Structured Forms or FormSuite for Invoices for your legacy applications, the increased flexibility of the FormSuite Cloud Beta is worth investigating.

Use Cases for Cloud-Based Form Capture

There are several scenarios for different industry use cases where cloud-enabled forms automation could create efficiency and reduce cost.

Insurance: Are clients applying for coverage by filling out paper forms? Claims for health expenses, property damage, or car accidents are all handled through your user-facing application.

Legal: How do attorneys capture retainer forms or engagement letters? Whether your law firm specializes in real estate, corporate mergers and acquisitions, or criminal matters,  processing the various forms involved in case files is a tedious manual task. 

Government: Permit applications, census forms, tax forms, invoices, and business registration forms are a few examples of documents which often start out as paper documents, but are best stored and processed electronically. Extracting personally identifiable information (PII) from forms and storing data in secure systems mitigates the risk of compromising sensitive data.

Finance: Applications for mortgages, business loans, 401Ks, and other investments often starts with a physical form. The data within these forms often changes after the initial signature ink dries. Pulling accurate data out of these forms in a timely manner is critical. 

A Cloud-Based Forms Solution for All

Whatever industry your business applications serve, it’s quite likely that much of the data which they store will come from a form. Coding your own forms capture functionality into your application adds cost and complexity to development lifecycles. That is entirely avoidable. 

Accusoft has been preparing a cloud-based version of our proven FormSuite SDK. A Beta API is now available for a test-drive. Explore how you can extend your business applications by recognizing key form fields and capturing the data that resides there. Sign up for to test our FormSuite Cloud Beta today. 

While PrizmDoc features are always a great way to add value to your application, our innovative document viewer is customizable to fit your brand and your preferences. PrizmDoc has a variety of customization options available for developers. While you can find all of these modification options in the documentation, let’s discuss keyboard shortcuts.

Keyboard shortcuts create a positive user experience. Here are a few ways you can customize the PrizmDoc keyboard shortcuts.

The Viewing Client includes support for some keyboard shortcuts. This topic will walk through how the jQuery.hotkeys plugin (https://github.com/jeresig/jquery.hotkeys) is used to support adding keyboard shortcuts, as well as how easy it is to remove the built-in keyboard support.

• Keyboard Key Combinations for Page Navigation
• Zoom in / Zoom out
• Delete Selected Marks
• Modal Dialogs
• Adding Keyboard Support without using jQuery.hotkeys Plugin
• Example Code for using pageup and pagedown Keys

The current implementation represents some (but not all) that can be accomplished with keyboard shortcuts. The currently supported keyboard combinations are detailed in the tables below:

Keyboard Key Combinations for Page Navigation

Zoom In / Zoom Out

Delete Selected Marks

Modal Dialogs

1. e-Signature dialog
2. Image stamp selection dialog
3. Page redaction dialog
4. Download document dialog
5. Print dialog
6. About box

The viewer.js contains a method, initKeyBindings, that contains the code to handle the keyboard support as described in the above tables. This method is called in the initializeViewer method. In order for the keyboard shortcuts to work, jQuery.hotkeys.min.js file is required. This file must be referenced in the Viewing Client’s start page, default.aspx for .NET sample, index.php in the PHP sample and index.jsp in JSP sample.

&ltscript src="viewer-assets/js/js/jQuery.hotkeys.js">&lt/script&gt

*Note: Do not obtain the file from CDN. It is broken. The non-minified version can be obtained from GitHub: https://github.com/jeresig/jquery.hotkeys This is a small file and it is recommended that you read all the details about the plugin before using it in your Viewing Client.

If you either have your own implementation of the keyboard support or prefer not use this implementation in the viewer.js, simply comment out the call to initKeyBindings() in the initializeViewer method. Also, you can choose to remove the initKeyBindings method definition completely from your copy of the viewer.js.

As an example, let us walk through a snippet of code in the method initKeyBindings for the ‘pageup’ key support for scrolling one page up.

$('body').on('keydown', null, 'pageup', function () {
    if ($(viewer.viewerNodes.$pageList[0]).is(':visible')) {
            //make sure modals are not up
            if (!$(viewer.viewerNodes.$overlayFade[0]).is(':visible')) {
                   //change to the previous page
                   viewer.viewerControl.changeToPrevPage();
                   return false;
            }
       }
       return true;
});

We can also change the code above to trigger the event on the whole document object.

$(document).on('keydown', null, 'pageup', function () {
   if ($(viewer.viewerNodes.$pageList[0]).is(':visible')) {
        //make sure modals are not up
        if (!$(viewer.viewerNodes.$overlayFade[0]).is(':visible')) {
              //change to the previous page
              viewer.viewerControl.changeToPrevPage();
              return false;
         }
    }
    return true;
});

In the above example, line 1 binds the keydown action of the ‘pageup’ key to the in-line handler. For the Viewing Client, the node with the selector attribute ‘pageList’ is the parent node. Therefore, the handler code checks to see if this node is visible. Also, since we do not want the page navigation to occur when the modal dialogs are showing, in line 4, we check for the visibility of the modal dialogs.

Because our elements are divs and are not normally focusable, we use a wider net and use ‘body’ as the target node of the key events. When nothing in particular has focus, document.body acts as a target node of key events. You can choose to bind to other elements beside the ‘body’ but you may need to give it a tab index. But be mindful, it may not provide expected results in all the browsers. Most browsers have native keyboard focusable support for the following element types:

1. Input elements
2. Buttons
3. Link elements

There are other things to consider too. Most browsers provide the following keyboard event types:

1. ‘keydown’
2. ‘keyup’
3. ‘keypress’

The method initKeyBindings also contains some commented out code that demonstrates how to provide keyboard support for the buttons in the modal dialogs.

Adding Keyboard Support Without Using jQuery.hotkeys Plugin

First, set up the Viewing Client as you would normally.

function initKeyBindings (viewerControl) {
  var handler = function(ev){
    return handleGlobalKeypress(ev, viewerControl); 
  };
   
  $(document).on("keydown", handler);
}

var pluginOptions = {
  documentID: viewingSessionId,
  language: languageItems,
  template: htmlTemplates
};

$(document).ready(function () {
  var viewerControl = $("#viewer1").pccViewer(pluginOptions).viewerControl;
   
  initKeyBindings(viewerControl);
});

Example Code for Using Pageup and Pagedown Keys

This code does not check for modal dialogs but the check can be added as shown in the examples above.

function handleGlobalKeypress (ev, viewerControl) {
  //check for keys
   switch (ev.keyCode) {
     case 33: // Page Up
       ev.preventDefault();
       viewerControl.changeToPrevPage();
       return false;
     case 34: //Page Down
       ev.preventDefault();
       viewerControl.changeToNextPage();
       return false;
   }
}

For more tutorials on customization, visit the PrizmDoc documentation today!