Technical FAQs

Printers, scanners, and other imaging devices have long been a source of headaches and frustration for developers and users alike. All too often, multiple software tools are required to connect an application to a device and acquire image files from them. This not only slows down workflows, but also creates opportunities for human error. Files can easily be misplaced or imported using the wrong parameters under these conditions.

Thanks to ImageGear’s TWAIN scanning support, however, developers can ensure that their application makes acquiring images from compatible devices both straightforward and mistake free. 

What Is TWAIN?

Developed in 1992 by a consortium of software developers and hardware manufacturers, the TWAIN standard is a standard software protocol and API that facilitates communication between imaging devices and software applications running on a computer. The word itself refers to a famous line in the Rudyard Kipling poem “The Ballad of East and West” that reads “never the twain shall meet.” Although sometimes alleged to stand for “Technology Without An Interesting Name,” the term is not actually an acronym despite being capitalized.

The name is well chosen because the TWAIN standard helped to solve the enduring problem of getting imaging devices and computers to connect and send data between one another. Most commonly used for scanners and digital cameras, TWAIN made it possible to request an image file to be imported into an application without having to utilize additional software or input commands using the physical device.

Implementing TWAIN Scanning with ImageGear

As a versatile image processing SDK, ImageGear fully supports the TWAIN specification, which allows developers to support any TWAIN-capable device directly into their applications. In most instances, this will involve adding a “Scan” button or option somewhere in the platform’s interface so that users can quickly and easily instruct their scanner to capture an image and pass it along to the application’s storage or workflow. Developers can also use the integration to adjust device settings directly from their application, such as changing the scanning area, modifying brightness and contrast, or increasing/decreasing dots-per-inch (resolution). 

ImageGear’s TWAIN scanning feature works with three external elements to facilitate image file transfers:

• The Device: Usually a scanner or digital camera, this is the primary imaging source. The device must be compliant with TWAIN protocol.This is typically indicated by the manufacturer.
• Data Source: Although ImageGear’s TWAIN scanning features can connect an application to a scanner, the device still needs a software driver that allows it to communicate with the computer’s operating system.
• Data Source Manager: The TWAIN manager software provides a universal mechanism for managing and using data sources from different device manufacturers. Developed by the TWAIN consortium, it can be downloaded for free and installed wherever the application is running.

(Both the device’s data source driver and TWAIN data source manager should be included with its installation software. They are not provided by the ImageGear SDK).

Acquiring an Image Using TWAIN Scanning

ImageGear can configure an application to gather an image or set of images from a connected device with a few simple steps.

Step 1: Open the Data Source

Developers can set the application to automatically open a default Data Source. This is typically the best choice when only one scanner is available, as is often the case in a small workplace. They can also use the Data Source Manager to provide a list of all available Data Sources and let the user select the one they need.

Step 2: Adjust Settings

ImageGear’s TWAIN scanning features allow image acquisition parameters to be set through the application. Parameters such as page count and image size can be set to a common default, but developers can also give the option to obtain the various capabilities (listed as “ScanCaps”) and display them for users to select from. ImageGear supports a wide range of TWAIN-related capabilities.

Step 3: Acquire Image

After all settings are configured, the image can be scanned and loaded into an ImGearPage Class object. When acquiring a multi-page image, ImGearPages are loaded into an ImGearDocument Class object instead.

How ImageGear TWAIN Scanning Looks in Code

As an example, here’s what the C# code may look like when using ImageGear to help an application import an image from a TWAIN Data Source:

using System;
using ImageGear.Core;
using ImageGear.TWAIN;

public ImGearPage AcquireImage(IntPtr Handle)
{
    ImGearPage igPage = null;
    ImGearTWAIN igTWAIN = new ImGearTWAIN();

    igTWAIN.WindowHandle = Handle;
    igTWAIN.UseUI = true;

    try
    {
        // Open the data source selection dialog
        igTWAIN.OpenSource(String.Empty);

        // Initialize the scanning
        igPage = igTWAIN.AcquireToPage();
    } 

    catch(ImGearException e)
    {
        // Handle the exception ...
    }

    finally
    {
        if(igTWAIN.DataSourceManagerOpen == true)
        {
            igTWAIN.CloseSource();
        }
    }

    return igPage;
}

Expand Your Application’s TWAIN Support with ImageGear

Accusoft’s ImageGear SDK provides comprehensive support for a broad range of TWAIN devices, which makes it easier than ever for developers to control the scanning process directly from their applications. Integrating TWAIN scanning can streamline workflows and significantly improve the software user experience by completely eliminating the need to turn to external programs for image acquisition. ImageGear is fully compatible with multiple generations of the TWAIN standard, including TWAIN v1.6, v1.7, v1.8, v1.9, and v2.4.

In addition to TWAIN scanning support, ImageGear provides powerful image and document processing capabilities that can transform your application workflows. With extensive file conversion and compression features, it’s the best way to quickly integrate content management features into your platform. To get a glimpse of what ImageGear can do for your .NET application, download a free trial today and start building.

Adding document viewing features to an application can be a challenge. Although there are many open source options available, finding a suitable ASP.NET document viewer or .NET image viewer that provides the right level of flexibility and functionality often requires a more specialized solution. Fortunately, .NET developers have good options when the time comes to integrate document viewing into their software, which helps them to focus on other application features.

The API Document Solution

Rather than building a dedicated viewer within their .NET application, many developers instead turn to an HTML5 viewer integration that uses REST APIs for their document needs. Since these viewers work within the web browser and can support any programming language, they provide the right balance of versatility and performance for most software applications. An HTML5 document viewer ensures a consistent viewing experience across multiple software platforms and browsers used within an enterprise environment.

Of course, if all an application needed to do was view files, it could simply use one of many open-source solutions. The problem is that these viewers typically only view one type of file, which means that the application also needs the ability to convert files into different formats. Depending upon the library in question, this could quickly escalate into a code-heavy solution that bogs down application performance and introduces multiple security vulnerabilities. If poor conversion tools are put in place, there’s also a strong likelihood that documents will not render accurately.

An HTML5 viewer with the right APIs can easily overcome these document management challenges for a .NET application. Conversion, annotation, comparison, and redaction features can all be integrated as part of a comprehensive viewing framework that doesn’t require developers to build anything from scratch or rely upon intrusive plugins that create risky dependencies.

How Accusoft APIs Enhance Your .NET Application

Accusoft’s PrizmDoc Viewer was designed to provide a broad range of document processing capabilities in addition to its core HTML5 viewing features. Once integrated into a .NET application, it allows developers to deploy REST API calls to convert files into new formats, split and merge documents, create page thumbnails, markup documents, and perform high-volume text searches. As an HTML5 viewer, PrizmDoc Viewer can deliver all of that functionality right within the browser rather than resorting to external applications.

The primary advantage of REST APIs is that they can be used from any programming language, so they don’t have to be custom-built to serve as an ASP.NET document viewer. That versatility does come with a tradeoff, however. Processes like uploading files, converting them, and then downloading outputs all require a series of HTTP requests. While this isn’t a particularly difficult process, it is slightly more resource-intensive than a solution built using the same programming language as the application. 

That’s why we developed a .NET SDK library that wraps around the server-related functions of PrizmDoc Viewer. Available for both .NET Core and .NET Framework, this SDK library wraps around the server’s REST APIs to make it easier to utilize server functionality in .NET applications.

For .NET developers looking for a better way to view and process documents, the PrizmDoc .NET SDK can help them access conversion, redaction, and annotation features without compromising the performance of their .NET applications.

Getting Started with PrizmDoc .NET SDK

In order to implement the .NET wrapper, developers just need to follow a few simple steps. 

1. Gain Access to a PrizmDoc Server Deployment

There are two ways to access PrizmDoc Server, which will allow you to carry out a variety of document processing functions. You can host a server on-premises as part of a PrizmDoc Viewer integration or sign up for a PrizmDoc Cloud account to use Accusoft’s cloud-hosted deployment.

2. Add the PrizmDoc Server .NET SDK Package

Next, download the free, open source .NET SDK library from NuGet or GitHub and add it to your application project.

dotnet add package Accusoft.PrizmDocServerSDK

3. Create a new PrizmDocServerClient

Once the .NET wrapper is in place, it’s time to construct a new PrizmDocServerClient and connect it to the server.

For a self-hosted PrizmDoc Server that’s part of a PrizmDoc Viewer deployment, the base URL is all that’s needed:

var prizmDocServer = new PrizmDocServerClient("http://localhost:18681");

If the you’re using PrizmDoc Cloud, you’ll need to provide the base URL along with your API key:  

var prizmDocServer = new PrizmDocServerClient("https://api.accusoft.com", "YOUR_API_KEY");

4. Begin Document Processing

Now that everything is in place, you can start processing and viewing documents within your .NET application. Our How To Guides provide some examples of common use cases, and you can also turn to the API Reference for additional guidance and information.

Get the Document Viewing Features Your .NET Application Needs

Accusoft’s PrizmDoc Viewer delivers the versatile HTML5 viewing capabilities that can set your .NET application apart from the competition. Thanks to the PrizmDoc Server .NET SDK wrapper, you can leverage the power of our REST APIs without needing to build out a customized viewing solution from the ground up.

Find out how easily you can manage your document needs with PrizmDoc Viewer’s browser-based functionality today. Sign up for a free trial to test our HTML5-powered viewer in your .NET environment.

One of the more challenging aspects of developing SDKs with machine learning models is deployment and productionization. TensorFlow in particular can be difficult to set up, and requires GPUs to evaluate large models. This post will share my experiences in skirting this process entirely to quickly evaluate a FasterRCNN-based model during a hackathon last year, usable on any office or CI machine.

During this hackathon, I implemented and trained a model from a paper from ICDAR 2017 on one of our physical machine learning-equipped machines. To achieve quick deliverables, rather than try to get the trained model and data off the machine, I simply used a tool called Luminoth running on the machine to expose the model’s prediction functionality. This also allowed anybody on my team to continue developing the model afterward with minimal friction, and required only a small networking shim in our codebase.

Luminoth is a Python-based tool that I like to refer to as “a command line wrapper around TensorFlow.” While the use of a YAML file to quickly set up and train some popular networks such as FasterRCNN is its main use, it also exposes a Flask-based server which allows prediction queries via a web page. As it turns out, it also exposes an (undocumented) API which is usable programmatically.

My codebase is in C++ with a C# assembly wrapping it. That being the case, I had to get my model’s predictions (a number of bounding boxes) into C++ code, and fast. Figuring out TensorFlow’s shaky C++ API (or even using Python-based TensorFlow) wasn’t an option. The model was already trained on our machine-learning computer, and would have required a large setup cost and data duplication by anyone else evaluating the model. I had my eye on a particular C++ networking library, CPR, that I have been meaning to use; so I thought, why not tackle all of these problems at once?

Let’s start by figuring out Luminoth’s API from the source and web page itself.

First, using Lunimoth’s server as per the documentation shows requests being made to an endpoint named `api/fastercnn/predict`. We can see it’s returning some JSON–great, we now know it’s probably possible to invoke programmatically!

Digging in Luminoth’s web.py, around line 31 at the time of writing, the corresponding endpoint `/api//predict/` method is our ticket.
The first thing we see is an attempt to retrieve the image data from the request to predict:

try:
  image_array = get_image()
except ValueError:
  return jsonify(error='Missing image'), 400
except OSError:
  return jsonify(error='Incompatible file type'), 400

What is get_image() ? Well, it shows an expectation of a POST’ed file by the name of ‘image’.

def get_image():
  image = request.files.get('image')
  if not image:
          raise ValueError
          image = Image.open(image.stream).convert('RGB')
  return image

This is a Flask web server. The Flask documentation for the files property in the Request object shows that this only appears (for our purposes) in a POST request, with a <form> object, and when an encoding of enctype=”multipart/form-data” is given. Right, sounds like we now know how to use the endpoint programmatically. Now, how can we call this from C++ using CPR?

Let’s start with the POST request. Using CPR, this is very straightforward. The required multipart/form-data encoding is handled by the cpr::Multipart object. At the time of writing, there is a bug with that and data buffers; so in order to proceed with the hackathon, the image was first written to a file, reloaded, and then sent. Don’t do that if possible.

extern "C" __declspec(dllexport) void* SendImagePostRequest(const char* url, unsigned char* data, int data_size)
{
    std::string filename = WriteTemporaryFile(data, data_size);
    auto response = cpr::Post(
            cpr::Url{ url },
            cpr::Multipart{{ "image", cpr::File{ filename } }});
    std::remove(filename.c_str());
    return ParseJsonResults(response.text);
}

Where url is the URL of the Luminoth endpoint we found, and data and data_size are the image we are trying to use FasterRCNN to predict. When used, it looks like this:

void* resultsHandle = predictTables("http://beast-pc:5000/api/fasterrcnn/predict/", image.data(), (int)image.size());

The POST request returns a JSON string. We need to decode it. Luckily, there is superb header-only Json library, Nlohmann Json (which I think has the potential to be part of the C++ STL; by all means use it), we can drop right in and get a vector of RECTs and their confidences back:

static std::vector* ParseJsonResults(const std::string& response)
{
    auto json = json::parse(response);
     std::vector* results = new std::vector();
     for (const auto& object : json["objects"])
    {
            const auto& bbox = object["bbox"];
            float confidence = object["prob"];
            results->emplace_back(RECT { bbox[0], bbox[1], bbox[2], bbox[3] }, confidence);
    }
     return results;
}

Note that the boxes are returned in a X/Y/Right/Bottom format. If you need a X/Y/Width/Height format, it’s easily convertible. From then on, the bounding boxes can be passed on throughout the codebase, and improvements of the method over current methods can be measured.

You’ll have to excuse the use of void pointers, pointers to vector, new, and other frowned-upon items. The use of CPR also required an additional problem here. The C++ codebase is in MSVC 11.0, and CPR requires MSVC 14.0 or later. To integrate this, a separate DLL was created and loaded dynamically via LoadLibrary in the main source, so a C API was created. But these are implementation details. And again, it was simply the quickest way to get results.

That’s about it for this post. All-in-all, I believe Luminoth is an underrated, but also unfinished, machine learning tool. It’s a good choice for having a quick way to train, save state, and evaluate neural networks. The API allows high-speed integration of a model into existing code in any language, after which a results analysis can determine if to further productionize the model or not.

Financial institutions are spending on technology. As noted by IDG Connect, solutions such as AI-driven analysis and investment tools could boost revenue by 34 percent. In addition, 72 percent of senior management view artificial intelligence and machine learning (ML) as critical market advantages.

It makes sense. Banks, credit unions, and fintech firms must now meet evolving consumer expectations and satisfy emerging compliance legislation. The challenge? Ensuring existing processes — such as check image handling at ATMs and data verification during loan applications — are both streamlined and secure.

Fortunately, there’s a simple starting point: image processing.

Bridging the Data Divide

According to a recent Accenture survey, several emerging trends now inform the consumer landscape in finance. What’s the most important to data-driven organizations? Trust. While 67 percent of clients will now permit banks access to more personal data, 43 percent cite trust as the biggest driver of long-term loyalty. What’s more, 63 percent want banks’ use of personal data to drive more individualized, value-added services.

ATMs provide a key component of this data-driven strategy. For example, many ATMs use the X9.100-181 standard to store and secure .tif files. To ensure customers and bank staff have access to the right data at the right time, companies need image software capable of capturing, processing, and manipulating these images in real-time — in turn underpinning the development of agile web-based and mobile applications that engender consumer trust.

Processing, Permission, and Potential

Also critical for banks? Compliance. Consider the evolving standards of GDPR. As noted by Forbes, the regulation includes provisions for the right to access, which entitles consumers to information about how and why their data is processed by organizations.

Given the sheer volume of data now processed by financial institutions — and the growing risk of network data breaches — meeting compliance expectations is both time and resource intensive. Add in the increasing number of consumers now submitting checks via ATMs or mobile deposit software, and companies face the problem of accidental data misuse. What happens if check or loan data is shared across departments but customers haven’t specifically given their permission?

Redaction can provide the security you need to keep sensitive information secure. By combining ease of capture with straightforward redaction services, it’s possible for banks to ensure that check and application X9.100-181 .tif data is natively secured, in turn limiting potential compliance pitfalls.

Controlling Complexity: Not Always Black and White

In the years following 2008’s nationwide financial collapse, many financial firms drafted long-term plans designed to reduce complexity and streamline operations. According to a recent Reuters piece, however, despite ambitious plans “the level of complexity remains high for U.S. banks.”

Here, consumer expectations and compliance demands conspire to increase total complexity. From cloud-based technologies to mobile initiatives and ongoing compliance evaluations, streamlining processes often takes a back seat to mission-critical operations. Check imaging and recognition is no exception. Companies need tools capable of handling color, black and white, and multi-layered images. The solution? Powerful software development kits (SDKs) that integrate with existing apps to provide on-demand functionality.

Piece by Piece

Meeting consumer expectations, satisfying compliance requirements, and reducing complexity is a multi-faceted, ongoing process for financial organizations.

Accusoft’s ImagXpress SDK provides a critical piece of this long-term goal with support for 99 percent of common financial image types, optimized compression/decompression technology to minimize wait times, and enhanced redaction and editing capabilities to empower ATM, loan application, and mobile app image processing. Learn more about Accusoft’s SDKs and APIs here.

Although PDFs are one of the most common document types in use today, not every PDF file is identical. A document with multiple layers, annotations, or editable form fields can create significant challenges for an application, especially when it comes to viewing, printing, and OCR reading. One of the most effective ways of dealing with these PDFs is to use powerful digital tools that “flatten” the document to remove unseen or unnecessary information to reduce the overall complexity of the file.

What Is PDF Flattening?

Flattening can be used to refer to a number of different processes, but in principle, they all accomplish the same goal of merging distinct elements of the document. A few example of flattening include:

• Making interactive form elements non-fillable and static.
• Burning annotations into the document to make them native text.
• Combining multiple layers of text or images into a single layer, eliminating any non-visible elements.

3 Reasons to Flatten PDFs

There are numerous reasons why an end user may wish to flatten a PDF document, but they usually fall under one of three broad categories.

1. Better Security

Forms often contain valuable information, especially when it comes to financial, insurance, or government forms. If a PDF with editable forms were to fall into the wrong hands, someone could easily alter the information contained in the form to commit fraud or falsify data. By flattening the forms, the entries become a static element of the document and cannot be altered any further. By building applications with the ability to flatten PDF forms, developers can help organizations protect themselves and their customers from the threat of falsified forms.

2. Faster Viewing

Speed is often crucial when it comes to viewing or processing documents. The more information is contained in a PDF, the longer it takes an application to render and view it. While this is sometimes a byproduct of file size, complex or poorly-designed forms can also make a PDF less responsive. Flattening a multi-layered PDF into a single, flattened layer eliminates hidden elements and makes the document much easier to read. This can also apply to forms, which often contain substantial annotation information. Eliminating forms simplifies the document, allowing it to render more quickly.

3. Easier Printing 

Many PDFs contain hidden data that is not visible on a viewing screen, but turns up on the page when the document is printed. Buttons and dropdown fields, for instance, can make a printed document look cluttered and confusing. When form fields are flattened, hidden annotation data is removed, eliminating any unpleasant surprises when the document hits the printer tray. For PDFs with multiple layers and hidden elements, flattening ensures that only the visible portions of the document will appear on the printed version.

How to Flatten a PDF Form Field Using ImageGear

With ImageGear, converting interactive form fields into static page content is a simple process that can be accomplished programmatically before documents are read by an OCR or ICR engine. It can also remove XFA form data, which often creates challenges for forms processing software.

ImageGear provides two options for flattening form fields. Although nearly identical in name, they perform somewhat different functions and should be used in different instances.

• FlattenFormField: Flattens specified fields into the page.
• FlattenFormFields: Flattens every field contained in the PDF into the page.

During the flattening process, a boolean can be used to indicate which fields should appear during printing, which is useful for hiding interactive elements that have no use on a printed page (such as buttons). Each field contains annotation information that determines how it should be represented on the page. Fields typically features one of three flags to dictate their representation:

• HIDDEN: Any field with this category will not appear on the page after flattening.
• NOVIEW: This field will only be visible on the page if “forPrinter” is specified during the flattening process.
• PRINT: These fields will appear on the page whether or not “forPrinter” is specified. If a field does not have the PRINT flag, it will only appear when “forPrinter” is not specified.

Dealing with XFA Forms

Although officially deprecated by international open PDF standards, Adobe’s proprietary XFA forms are still found in many PDF documents. Opening and editing a PDF that contains XFA data often creates exceptions that make them difficult to manage when it comes to extracting forms information. ImageGear FlattenFormFields function will remove any XFA data from a document during the flattening process.

How to Flatten a PDF for OCR Processing with ImageGear

While flattening forms is an effective way of simplifying a document, it doesn’t change the file format itself. The document itself is still a PDF. So while ImageGear’s form flattening features are an effective solution for managing PDFs securely, another approach is often needed for OCR image processing.

Consider, for instance, an insurance solution that needs to be able to extract data from a wide variety of forms. Some of these documents are interactive PDFs with editable forms, some are static PDFs, and still others are scanned images of a document. Rather than devising multiple strategies for dealing with each document type, the solution can streamline the process by simply rasterizing every PDF it receives into an image file, which effectively flattens any form elements it contains.

Once the PDF is flattened into an image, it can easily be run through an OCR engine to match it to the correct form template and then send it to the appropriate database or extract specific form information. This process ensures that all documents coming through the solution can be handled the same way, which makes for a more streamlined and efficient workflow.

Expand Your Application’s PDF Capabilities with ImageGear

Flattening PDFs is just one of many features developers can incorporate into their applications with Accusoft’s ImageGear SDK. Other core functionality includes the ability to annotate, compress, split, and merge PDF files, as well as convert multiple file types to or from PDF format. ImageGear also provides a broad range of PDF security features like access controls, encryption settings, and digital signatures. Get a hands-on trial of ImageGear today for a closer look at what this powerful SDK can do for your application.

As part of our ongoing commitment to supporting the LegalTech industry in its effort to transform the processes used by law firms and legal departments, Accusoft recently sponsored an educational webinar in conjunction with Law.com entitled “Build or Buy? Learning Which Is Best for Your Firm or Department.” Hosted by Zach Warren, editor-in-chief of Legaltech News, the webinar featured Neeraj Rajpal, CIO of Stroock & Stroock & Lavan, and Kelly Wehbi, Head of Product at Gravity Stack, a subsidiary of the Reed Smith law firm. 

Together, the panelists brought two unique perspectives to the ongoing “build vs buy” debate, both from the software vendors who provide LegalTech solutions and the decision makers working at the legal firms who make difficult decisions regarding technology solutions.

Build vs Buy: The Choices Before the Decision

Both Rajpal and Wehbi agree that any decision involving building or buying technology solutions has to begin with defining the problem a firm needs to solve. Regardless of whether you’re working with an independent legal firm or a legal department within a larger organization, it’s critical to understand the business problem, existing pain points, and potential value of a solution.

“When you start asking the right questions,” Raijpal notes, “you sometimes come across a situation where the requirements are not very clearly defined and that is a big red flag to me because when requirements are not defined, you’re not solving anything.”

Wehbi shares that concern about the requirements gathering process, pointing out that things tend to go wrong when firms fail to consider both the scope and magnitude of the challenge they’re trying to overcome. “Organizations can struggle a lot when they jump a little too quickly to a solution or to thinking about just what the return would be on a potential new product or service offered.”

It’s also critical to make sure that the firm is willing to accept some degree of change. If existing business processes are unclear or if no one is willing to consider changing how they work, then no amount of technology is going to make a difference. Understanding the culture of the firm and securing the buy-in from leadership is absolutely critical to making any technology integration succeed whether you’re buying a solution or building one from scratch. 

The Pros and Cons of Building LegalTech Solutions

For an organization that has the resources, methodologies, and skill sets necessary to develop a solution that’s specifically designed to meet its unique requirements, building can be a great decision. The key advantage here is that it focuses specifically on the firm’s processes and user pain points, allowing developers to design a solution that is much more targeted than an “off-the-shelf” product.

Benefits of Building

• Applications can be customized to your exact specifications, allowing them to better address your specific business needs.
• Since you manage the solution from end to end, you retain much more control in terms of application features and functionality, how data is managed, and access security.
• Developing a specialized solution creates room for innovative technology that can provide a competitive edge.
• A custom-built solution presents fewer integration challenges, especially when it comes to interfacing with legacy systems used by many legal organizations.

Risks of Building

• Building a new solution from the ground up requires a great deal of time and resources that might be better spent elsewhere.
• Investing in custom software creates substantial technical debt that must be maintained over time and could create integration problems in the future when additional upgrades are required.
• If the new solution doesn’t contribute enough to the bottom line to justify the cost of operations, it could lead to negative economies of scale that make it difficult for the firm to grow its business.

The Pros and Cons of Buying LegalTech Solutions

Not every organization has the development resources to build a customized solution from the ground up. If they’re not ready to make that capital investment, a cloud-based offering may be better suited to their needs. Leveraging a proven, ready-to-launch SaaS solution offers a number of advantages, but could impact how the company makes technology decisions in the future.

Benefits of Buying

• Since SaaS services are usually cheaper and easier to implement, they are often the best option for companies with limited IT resources.
• Cloud solutions are good for solving common technology problems that smaller firms face.
• Already-live functionality means SaaS solutions can be implemented on a faster time frame.
• The cloud vendor handles all building and maintenance costs associated with the platform.
• Since the vendor sets up workflows and integrations as well as troubleshooting, your internal team is freed up to focus on other tasks.

Risks of Buying

• Off-the-shelf solutions offer less customization and control over infrastructure and data.
• Even industry-specific SaaS solutions are built for a general market in mind, so their features may not solve your firm’s unique requirements.
• Since the vendor manages security, customers have less oversight over how their sensitive data is managed.
• Working with a SaaS provider exposes firms to market risk. If the vendor goes out of business or sunsets a product, it may be difficult to repatriate data or transition to another provider.

When to Build

For firms with the development resources that are already using in-house document management solutions to streamline processes, SDK and API integrations are often the best way to enhance functionality. Accusoft’s PrizmDoc Suite leverages REST APIs and advanced HTML controls to provide powerful document viewing, conversion, editing, and assembly capabilities to web-based applications. Our SDK integrations also allow developers to build the functionality they need directly into their software at the code level.

Document Assembly

Law firms need automation solutions that allow them to easily create and manage multi-part, multi-stage contracts. Thanks to Accusoft’s PrizmDoc Editor, legal teams can rapidly identify and assemble sections of pre-existing text into new content that is both editable and searchable. PrizmDoc Editor integrates securely into existing applications and delivers in-browser support to help lawyers assemble assets without resorting to risky external dependencies.

Case Management

LegalTech applications can manage and review cases much more efficiently by integrating data capture, file conversion, and optical character recognition (OCR) capabilities. The ImageGear SDK helps legal teams access case data in a variety of formats without the need for downloading additional files or relying on third-party viewing applications. It can also convert multiple file types into secure and searchable PDF/A documents, making it easy to tag files with client numbers, names, and other identifiable information. Thanks to PDF/A functionality, ImageGear ensures that firms can stay on the right side of federal regulations.

eDiscovery

The rapid transition to predominantly digital documents has fundamentally altered the way legal organizations approach the discovery process. Innovative eDiscovery processes can streamline case management while also protecting client interests. In order to implement these strategies effectively, firms need applications that provide extensive file format support and search functionality as well as redaction and digital rights management (DRM) tools capable of protecting client privacy. PrizmDoc Viewer delivers these features along with scalable annotation capabilities that make it easier for collaborators to proofread, review, and make comments to case files without creating version confusion. As an end-to-end eDiscovery toolkit, our HTML5 viewer also includes whitelabeling support so it can be fully integrated into your application’s branding.

When to Buy

For smaller legal teams looking for broad functionality without development hassles or a new firm taking its first steps toward document automation, it often makes more sense to implement a bundled, buy-in solution like Accusoft’s Docubee SaaS platform.

Document Completion

Docubee makes document management easy with drag and drop data routing. Users can quickly create legal contracts, route the appropriate data to documents, deliver contracts for approval, and facilitate signing with secure eSignature technology. 

Customized Templates

With Docubee, legal teams can create customized document templates and manage them on a section-by-section basis. Individual clauses can be added or removed as needed, allowing attorneys to repurpose document templates instead of creating them from scratch for every client. 

End-to-End Support

Two-way communication support helps firms to build better dockets and negotiate more effectively. Documents can be updated automatically and version controls ensure that everyone is always looking at the most up-to-date version of a contract. Docubee also allows users to prioritize key tasks with collaborative redlining and notification tools.

Long-Term Storage and Security

Docubee stores data for up to six years to meet eDiscovery requirements. To better protect client privacy and meet changing compliance requirements, firms can also set destruction dates for contracts, templates, and case files. Docubee is SOC2 compliant, featuring multi-layer encryption to keep data under tight lock and key.

Hear the Full Conversation

To hear the full webinar and learn more about how legal firms make the difficult choice between building or buying their next technology solution, sign up now to get access to an on-demand recording of the event. If you’re ready to learn more about how Accusoft technology is helping to power innovation in the legal industry by delivering the latest in content processing, conversion, and automation solutions, visit our legal industry solutions page or contact us today to speak to one of our product experts.

Jeffrey Hodges, Accusoft Senior Software Engineer

Many factors are important for generating the best possible OCR results from image documents. One of the most important factors is to start with the best quality image possible. The OCR accuracy has a direct correlation to the quality of the document. While OCR is usually done on a black-and-white binary document, it would be better to scan the document to an 8-bit or higher bit depth image. This greater image depth can be useful for many of the image processes necessary to clean up scanner artifacts. These include light and dark specks, skew, warp, and border artifacts.

Eliminate Border Artifacts

Scanned images always have some artifacts that affect the quality of the document. Pages are almost never exactly aligned within the scanner. One effect is the addition of a border line into the image. This border is outside of the original page being scanned, but is included in the scanned document. This also happens when the page is smaller than the scanner surface. These border effects are not part of the original page and should be removed. These documents should be clipped to remove the border defects, otherwise when performing OCR these regions may yield erroneous data, increasing recognition errors.

Correct Skew

Skew is a very common effect that occurs when scanning documents. It almost always needs to be accounted for when performing OCR, otherwise the text can be

Correct Perspective Warp

When images are taken from a camera or phone, and not from a flatbed scanner, more distortion will occur. The camera takes in the whole image and there is always some distortion at different angles. Perspective warp correction is required to allow for the non-linear transformation across the image.

Eliminate Noise

The most common type of noise is extra specks within the document. These specks could be both light or dark and are most likely to occur when the document is scanned in black and white. Speck removal is the elimination of these small stray marks in the image without removing important pixels. Overaggressive speck removal will negatively affect text recognition accuracy by removing correct objects such as periods, the dot above the letter i, or other small marks, but under-removal of the specks leave noise that may be incorrectly recognized as text.

Summary

Most OCR is performed upon binary images to enable faster analysis, transforming the scanned document to text data. By scanning the document in a higher bit depth, advanced image processing can improve the quality of the document for further processing. Following this, binarization (the process of intelligent color detection and reduction of the bit depth to 1 bit per pixel) is performed to change the document to a black-and-white image suitable for OCR processing. Choosing the correct binarization algorithm can also smooth the background and flatten color regions.

Accusoft’s ScanFix Xpress SDK provides advanced document image processing to automatically clean up and improve document quality. Automatic image cleanup processes within ScanFix Xpress yield improved accuracy of subsequent OCR processing. These clean up processes also improve forms processing and intelligent character recognition (ICR).

Jeffrey Hodges is a Senior Software Engineer in the SDK division of Accusoft Corporation. He is an expert in document recognition technologies with over 20 years developing innovative solutions.

Getting Started with PrizmDoc Viewer.  Searching for documents wastes time. Almost five hours a week for many information workers. But it doesn’t stop there. Documents require third-party applications to view, edit, and share. PrizmDoc™ Viewer integrates with your existing applications to deliver in-browser viewing that displays accurate and complete document content on-demand. Ready to get started? Here’s what you need to know.

Architecture Overview

Let’s start with the basics. What pieces do you need?

PrizmDoc Viewer contains three key components:

• The HTML5 Viewer — This runs in-browser to display your content.
• The Backend — This converts documents to SVG format for viewing.
• The Reverse Proxy — This is your web application. It sits between the viewer and the backend to request your content.

The backend itself has two components: PrizmDoc Application Services (PAS) and PrizmDoc Server. Both run on their own hosts or ports using their own REST APIs. PrizmDoc Server is the computing powerhouse of Accusoft’s document viewer — the actual engine that converts documents to SVG. 

PAS, meanwhile, has privileged access to your source document storage and is responsible for functions such as pre-converted content caching and the saving and loading of annotations. PAS doesn’t do the heavy lifting of document conversion; instead, your web app makes REST API calls to PAS, which in turn calls PrizmDoc Server to complete the conversion and serve SVG documents. 

If you need direct conversion for non-viewing work such as file format changes or burned-in annotations, your web app can make REST API calls directly to the Server.

Illustrating the Viewing Sequence

Next up: How does this all work?

Think of it like a conversation.

First your web app POSTs to PAS and asks for a new viewing session. PAS responds with a new ViewingSessionID. This lets your web app render the page HTML and pass it along to the in-browser document viewer, while simultaneously delivering original documents to PAS.

PAS talks to PrizmDoc Server, asking it to start conversion. Meanwhile, the document viewer has its own question for the PAS (via your web proxy): Can I have the first page now? Once available, PAS sends the first page back as an SVG even as other pages are still being converted, letting users view and interact with documents while conversion is underway. 

Sample Applications

How it all comes together: What does this look like in practice?

Start simple. Use one of our minimal “hello viewer” sample applications to see PrizmDoc Viewer in action. The Node.js, C#, and Java apps all load a single document into the browser using PrizmDoc, making it easier to visualize how the HTML5 viewer, your reverse proxy, and the PrizmDoc backend interact to deliver SVG content on-demand. From here, it’s easy to scale up and start converting, viewing and annotating documents at scale — all without leaving your application.

Document access drives productivity. Time spent searching for conversion tools puts on the breaks. Make it easier for staff to view the content they need, when they need it by integrating in-browser, in-app, on-demand document viewing. Try PrizmDoc Viewer on your own terms and on your own timeline.  Getting started with PrizmDoc Viewer is easy!  Try it now.

It’s that time of year again – the top coding trends for the year. The time when many companies take a look back at the market forces which influenced their industry segment over the past year, and start looking ahead and planning for the year ahead. The rapid pace of change in application development constantly introduces developers to shiny new objects which promise to disrupt coding as we know it. Instead of dumping a truckload of tech tidbits on your browser, we’ve gathered five of the top trends we feel coders will care most about in the year ahead.

Top Coding Trends for 2020:

1. Microservices Will Go Mainstream

2. Containerization and Container Orchestration

3. The Rise of .NET Core

4. DevOps and DevSecOps Adoption Will Continue to Grow

5. AI, Machine Learning, and Codeless Development

1.Microservices Will Go Mainstream

Over the past seven years or so, microservices architecture and development methodologies have steadily grown in popularity. Agile teams have embraced microservices as a way to:

• Speed up their development into shorter, concurrent sprints
• Make applications more scalable
• Taking a modular approach to their applications, and leverage APIs and SDKs where possible 
• Shorten release cycles and support continuous deployment and integration (CD and CI)
• Minimize dependencies and enable the testing and delivery of independent services without risking knocking out others

Many development teams have already adopted microservices architectures and methodologies, and many of the trends which follow support its growth and popularity. If you are planning to shift your coding strategies towards microservices, we have a four-part series of articles on best practices. 

2. Containerization and Container Orchestration

The last few years have seen rapid growth in the use of containers by developers. In the past four or five years, developers have been leveraging containers to accelerate the development of new applications and iterative upgrades. 

Docker and Kubernetes are both expected to grow, diversify, and empower developers to achieve greater:

• Development velocity, to continually ship updates without downtime
• Scalability, to scale workloads up or down as needed
• Resilience, as far as being able to enable developers to replace unhealthy containers and pods as needed to eliminate slow performance or downtime. 
• Agility, to introduce new applications and functionality into production without compromising performance or security.

Gartner predicts by 2022, 75% of global businesses will use containerized applications, compared to the approximately 30% that have been in 2019. Microservices development methodology is ideal for businesses running containers. 

3. The Rise of .NET Core

Like many application development teams, Accusoft coders have taken the opportunity to develop SDKs for .NET Core. It is simply faster and more secure for cloud-native applications. Businesses are adopting and running multiple cloud platforms like Azure, AWS, Google, and IBM. 

Cloud-native applications built on frameworks like .NET Core enables greater cloud flexibility. It even gives developers the freedom to code on devices like Mac and platforms like Linux. Developers will be able to focus more on what they are building than what they are building it on, as they can call up resources and middleware as they need them. Python development enthusiasm can’t be overlooked in the Java world and should continue to make waves in 2020.

4. DevOps and DevSecOps Adoption Will Continue to Grow

All of the trends identified above generally dovetail with DevOps practices and trends. In 2020, the focus will increase on the importance of strategic approaches to making data and cloud security across the organization. High-profile data security breaches at Capital One, Fortnite, and Facebook prove that hackers are exploiting every vulnerability they can find. 

DevSecOps emphasizes how application security is just as important in the application development lifecycle as functionality. Cloud applications are providing users with greater flexibility to where they can access corporate data, and the devices they can use to access it from. Every employee and executive must take data and document security seriously and take precautions to safeguard corporate information assets. 

5. AI, Machine Learning, and Codeless Development

Over the past few years, developers have worked with serverless and stateless architectures and network connections, but are they prepared for codeless development? The influence of artificial intelligence and machine learning is enabling low-code and no-code development practices. 

Though codeless applications have been met with scepticism, there is no questioning the influence of machine learning and process automation into the app development and workflow configuration arenas. As we gaze into the laptop-shaped crystal balls on our desks, these are the 2020 software development trends we are seeing at Accusoft. Follow us on Linkedin or Facebook to stay up-to-date on our industry trends and innovations we’re working on.