Technical FAQs

Today’s organizations are inundated with a variety of document and image formats on a regular basis. By integrating comprehensive PDF functionality into their applications, developers can provide the tools to manage those files much more easily. Converting files into PDFs makes them easier to share, modify, and annotate without having to worry about compatibility issues across applications.

Simply converting documents or images into searchable PDF files is easy enough, but in many cases, several files need to be merged into a single document or one large file must be split into multiple documents. Accusoft’s ImageGear SDK gives applications the ability to process PDFs programmatically, allowing users to quickly prepare documents for viewing and collaboration.

How to Merge PDF Files with ImageGear Using C#

ImageGear can merge two multi-page PDF documents into a single document. This is especially useful for organizations that have multiple files associated with the same workflow or account, such as loan applications or medical records. The following steps will walk you through the merge PDF process using ImageGear.NET in C#.

Step 1: Initialize PDF Support

Before getting started, you’ll need to initialize PDF support within ImageGear.NET (if you haven’t done so already during deployment). This initialization will allow your application to load, save, and process PDF files.

After creating a new “Console Application” and adding the required assembly reference and resources, you can use the following code snippet to load and save PDF files.

using System.IO;
using ImageGear.Formats;
using ImageGear.Formats.PDF;
using ImageGear.Evaluation;
namespace MyPDFProject
{
    class Program
    {
        public void Initialize()
        {
            // Initialize evaluation license.
            ImGearEvaluationManager.Initialize();
            ImGearEvaluationManager.Mode = ImGearEvaluationMode.Watermark;
            // Initialize common formats.
            ImGearCommonFormats.Initialize();
            // Add support for PDF files.
            ImGearFileFormats.Filters.Insert(0, ImGearPDF.CreatePDFFormat());
            ImGearPDF.Initialize();
        }
        public void Terminate()
        {
            // Dispose of support for PDF files.
            ImGearPDF.Terminate();
        }
        public void LoadAndSave(string fileIn, string fileOut)
        {
            ImGearPDFDocument igPDFDocument = null;
            try
            {
                // Load the PDF document.
                using (FileStream inStream = new FileStream(fileIn, FileMode.Open))
                    igPDFDocument = (ImGearPDFDocument)ImGearFileFormats.LoadDocument(inStream, 0, (int)ImGearPDFPageRange.ALL_PAGES);
                // Save the PDF document to a new file.
                ImGearPDFSaveOptions pdfOptions = new ImGearPDFSaveOptions();
                using (FileStream outStream = new FileStream(fileOut, FileMode.Create))
                    ImGearFileFormats.SaveDocument(igPDFDocument, outStream, 0, ImGearSavingModes.OVERWRITE, ImGearSavingFormats.PDF, pdfOptions);
            }
            finally
            {
                igPDFDocument?.Dispose();
            }
        }
        static void Main(string[] args)
        {
            Program myProgram = new Program();
            myProgram.Initialize();
            myProgram.LoadAndSave(@"C:\PATHTOPDF\FILENAME.pdf", @"C:\PATHTOPDF\NEWNAME.pdf");
            myProgram.Terminate();
        }
    }
}

       

Step 2: Set the Merge PDF Parameters

You will need to determine what order the documents will be combined in and set the page numeration for the new document.

Step 3: Merge the PDF Documents

Once you’ve identified the files you want to merge and the order they should go in, you can use the “MergePdfDocuments” command to assemble the new PDF file. Here’s what the code snippet looks like in C#:

        // Merges two PDF document into a third PDF document.
        public void Merge(string fileInFirst, string fileInSecond, string fileOut)
        {
            // ImageGear uses zero-based page numbers.
            const int FIRST_PAGE_INDEX = 0;
            ImGearPDFDocument igPDFDocumentFirst = null;
            ImGearPDFDocument igPDFDocumentSecond = null;
            ImGearPDFDocument igPDFDocumentResult = null;
            try
            {
                // Load the source PDF documents.
                using (FileStream inStream = new FileStream(fileInFirst, FileMode.Open))
                    igPDFDocumentFirst = (ImGearPDFDocument)ImGearFileFormats.LoadDocument(inStream, 0, (int)ImGearPDFPageRange.ALL_PAGES);
                using (FileStream inStream = new FileStream(fileInSecond, FileMode.Open))
                    igPDFDocumentSecond = (ImGearPDFDocument)ImGearFileFormats.LoadDocument(inStream, 0, (int)ImGearPDFPageRange.ALL_PAGES);
                // Create the resulting PDF document.
                igPDFDocumentResult = new ImGearPDFDocument();
                // Copy all pages of first document into resulting PDF document.
                for (int pageIndex = FIRST_PAGE_INDEX; pageIndex < igPDFDocumentFirst.Pages.Count; pageIndex++)
                    igPDFDocumentResult.Pages.Add(igPDFDocumentFirst.Pages[pageIndex].Clone());
                // Copy all pages of second document into resulting PDF document.
                for (int pageIndex = FIRST_PAGE_INDEX; pageIndex < igPDFDocumentSecond.Pages.Count; pageIndex++)
                    igPDFDocumentResult.Pages.Add(igPDFDocumentSecond.Pages[pageIndex].Clone());
                // Save the resulting PDF document to a new file.
                ImGearPDFSaveOptions pdfOptions = new ImGearPDFSaveOptions();
                using (FileStream outStream = new FileStream(fileOut, FileMode.Create))
                    ImGearFileFormats.SaveDocument(igPDFDocumentResult, outStream, 0, ImGearSavingModes.OVERWRITE, ImGearSavingFormats.PDF, pdfOptions);
            }
            finally
            {
                igPDFDocumentFirst?.Dispose();
                igPDFDocumentSecond?.Dispose();
                igPDFDocumentResult?.Dispose();
            }
        }
        static void Main(string[] args)
        {
            Program myProgram = new Program();
            myProgram.Initialize();
            myProgram.Merge(@"C:\PATHTOPDF\FIRSTFILENAME.pdf", @"C:\PATHTOPDF\SECONDFILENAME.pdf", @"C:\PATHTOPDF\NEWNAME.pdf");
            myProgram.Terminate();
        }

After merging your files into a new document, you can begin working with the resulting PDF using ImageGear’s other PDF features:

• Compressing PDF files
• Set PDF security features
• Manage PDF metadata
• Add watermarks to PDF
• Edit PDF content
• Extract text from PDF

How to Split PDF Files with ImageGear Using C#

While the merge PDF command is used to combine multiple documents into a new, single PDF file, the split PDF command saves pages from an existing document as a separate document. A three-page PDF file, for instance, can be broken into three, single-page PDF documents.

Once you’ve initialized PDF support for ImageGear.NET, you can split a PDF document by following a few simple steps:

Step 1: Read the PDF into a System.IO.Stream Object

This allows ImageGear to read the stream using ImGearFileFormats.LoadDocument(FILE NAME) command.

Step 2: Determine PDF Page Count

The ImGearPDFDocument.Pages property provides access to the document’s page array, which can then be used to assemble a new document.

Step 3: Create a New PDF Document

The ImGearPDFDocument object can be used to create an empty PDF document that will serve as the destination file for the split pages.

Step 4: Insert Pages into the New Document

The InsertPages command takes specific pages from the source document (the PDF you’re splitting), and inserts them into the destination document. After the pages are inserted, you can save the new PDF to disk or memory. Keep in mind that the original document will still contain all pages, so splitting it into two documents will require you to create two new documents.

Here is a what splitting a single PDF document into several single-page PDF documents looks like in C#:

public void Split(string fileIn, string directoryOut)
        {
            // ImageGear uses zero-based page numbers.
            const int FIRST_PAGE = 0;
            // Ensure output directory exists.
            if (!System.IO.Directory.Exists(directoryOut))
                Directory.CreateDirectory(directoryOut);
            // Load the source PDF document.
            using (FileStream inStream = new FileStream(fileIn, FileMode.Open))
            {
                using (ImGearPDFDocument igPDFDocument = ImGearFileFormats.LoadDocument(inStream, FIRST_PAGE, (int)ImGearPDFPageRange.ALL_PAGES) as ImGearPDFDocument)
                {
                    // Write each page in source PDF document to a separate PDF file.
                    for (int pageIndex = FIRST_PAGE; pageIndex < igPDFDocument.Pages.Count; pageIndex++)
                    {
                        // Construct the output filepath.
                        string outputFileName = string.Format("{0}_{1}.pdf", Path.GetFileNameWithoutExtension(fileIn), pageIndex + 1);
                        string outputPath = System.IO.Path.Combine(directoryOut, outputFileName);
                        // Create a new empty PDF document.
                        using (ImGearPDFDocument igPDFDocumentResult = new ImGearPDFDocument())
                        {
                            // Insert page into new PDF document.
                            igPDFDocumentResult.InsertPages((int)ImGearPDFPageNumber.BEFORE_FIRST_PAGE, igPDFDocument, pageIndex, 1, ImGearPDFInsertFlags.DEFAULT);
                            // Save new PDF document to file.
                            igPDFDocumentResult.Save(outputPath, ImGearSavingFormats.PDF, FIRST_PAGE, FIRST_PAGE, 1, ImGearSavingModes.OVERWRITE);
                        }
                    }
                }
            }
        }
        static void Main(string[] args)
        {
            Program myProgram = new Program();
            myProgram.Initialize();
            myProgram.Split(@"C:\PATHTOPDF\FILENAME.pdf", @"C:\PATHTOPDF\OUTPUTDIRECTORY");
            myProgram.Terminate();
        }

Enhance Your PDF Capabilities with ImageGear

Accusoft’s ImageGear SDK provides a broad range of document and image processing functions beyond the ability to split and merge PDFs. Whether you need powerful file conversion capabilities, multi-language OCR support, or image cleanup, correction, and transformation functions, ImageGear integrations can enhance your application’s performance and versatility. 

Learn more about the ImageGear collection of SDKs and see how they can help you shorten your development cycle and get your innovative products to market faster.

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.

FinTech applications have become indispensable to the financial services sector, enabling users to easily engage with financial offerings in a manner that suits them, while also boosting operational efficiency. The industry’s ongoing digital transformation continues to redefine FinTech functions, with developers tirelessly crafting new apps capable of handling tasks formerly dispersed across numerous systems and software.

Among the most crucial features of FinTech applications is the ability to view and share documents. Developers have a range of document lifecycle solutions at their disposal to circumvent the challenging process of building these features from the ground up. However, the financial sector presents distinct security and compatibility prerequisites when it comes to choosing partners for integration. To truly grasp these technical hurdles, it’s important to understand the significance of Java in the development of FinTech applications.

A (Brief) History of Java in the Financial Sector

Financial institutions pioneered the adoption of automated workflows. The advent of the first electronic communication network that facilitated the trading of financial products off the trading floor was seen as early as the 1960s. During the 1970s, computerized order flows saw greater acceptance, with most financial companies crafting their own proprietary systems. The digital revolution truly ignited in the 1980s and early 1990s with the launch of the Bloomberg terminal and the Financial Information eXhange (FIX) protocol. By the late 1990s, the Nasdaq enabled the execution of securities trades autonomously, without the need for manual interference, through the incorporation of Island ECN.

Java shook up the programming language world when it debuted in 1995, and its timing couldn’t have been better. The financial industry witnessed an extensive wave of mergers and acquisitions in the late 1990s and early 2000s, which resulted in several companies grappling with the integration of a multitude of applications and data. Java’s ability to support diverse platforms was an appealing solution to this challenge, and numerous financial applications were translated into Java. Sun Microsystems, which first introduced Java to the market, even adopted the slogan “Write once, run anywhere” to promote its flexibility. Java’s simplicity of use and significantly enhanced speed compared to legacy code on outdated platforms quickly made it the language of choice for developers.

In a few short years, Java ascended to become the leading programming language within the financial services industry. Its popularity surged again following the launch of OpenJDK, a free and open-source version of the language, in 2007. An Oracle report in 2011 estimated that over 80% of electronic trading applications and virtually all FIX engines were written in Java. Even close to three decades after its debut, Java continues to be the primary programming language employed by financial services, surpassing other open-source alternatives by a considerable margin.

Java’s Enduring Appeal for the Financial Industry

The enduring preference for Java among financial sector developers isn’t simply due to tradition or resistance to change. Java’s unique attributes are an exceptional fit for financial applications, spanning both long-established enterprise-level banking systems and pioneering FinTech solutions.

Security

In the realm of financial services, security is the highest priority for developers. Applications related to banking and trading must have robust security provisions to guard financial data and personally identifiable information against unauthorized access. Java simplifies data access restriction and provides an array of memory safety features to diminish potential vulnerabilities, particularly those stemming from prevalent programming mistakes. Oracle consistently rolls out regular updates to fix recognized vulnerabilities and tackle the most recent cybersecurity threats.

Portability

Java, being a platform-independent language, allows applications to operate on virtually any device. This has always been a substantial benefit in the financial sector, but it has proven even more crucial in the era of cloud computing and mobile applications. Developers can employ the same code to roll out software in a virtual environment and render it accessible to end-users via their smartphones, computers, or other devices. The ability of Java virtual machines to support additional programming languages only adds to the language’s versatility.

Reliability

Given the nearly three-decade-long consistent use and the backing of a robust development community, Java has established itself as one of the most dependable programming languages globally. Potential instabilities have long been addressed, and there is a wealth of developer tools and documentation at hand to ensure software is built on a solid foundation. This reliability is critically significant for banking and financial applications, which demand high performance levels coupled with fault tolerance.

The Value of Java-Based Document Viewing and Sharing

As FinTech developers continue to build novel applications aimed at simplifying life for clients and employees in the financial industry, they’re facing a growing expectation from users for superior document viewing and sharing capabilities. Users want to bypass the time-consuming and resource-heavy task of manually processing paper documents, and most organizations strive to eliminate the security hazards associated with using external applications for managing digital documents.

However, developers face significant challenges when attempting to build these complex document viewing capabilities from scratch. Although there are numerous integrations that can introduce document lifecycle features, most aren’t based in Java and need extra development work to embed them into existing FinTech solutions. Without the option to natively view, share, and edit documents within the Java application, users frequently resort to external programs, a practice that presents potential security issues and version discrepancy risks.

Facilitating Java-based Document Functionalities through PrizmDoc^® for Java

Accusoft’s PrizmDoc^® for Java, formerly VirtualViewer^®, is a robust, Java-based HTML5 document viewing tool designed to assure optimal compatibility with FinTech applications without compromising functionality and security. By supporting an array of document types, such as PDF, TIFF, JPEG, AFP, PCL, and Microsoft Office, PrizmDoc® for Java creates a streamlined viewing experience that eliminates the need for external viewing solutions.

As an integration built on Java, PrizmDoc^® for Java can operate on nearly any operating system and is simple to deploy. There’s no need to install software on the user’s desktop, enabling FinTech developers to deploy a scalable solution that fulfills their crucial security and business continuity needs within a single, high-velocity application. PrizmDoc^® for Java’s server component swiftly renders and dispatches individual document pages for local viewing as required, allowing users to access, view, annotate, redact, and manipulate financial documents instantaneously. Since documents are rendered within the web-based viewer, users never have to download or transfer files, which could put sensitive data at risk.

Experience PrizmDoc^® for Java’s features for yourself by signing up for a free trial!

Despite the explosive growth of big data and sophisticated analytics platforms, a 2019 study by Deloitte found that 67 percent of business leaders are not quite comfortable using them to inform decision making. For many organizations, spreadsheets remain the preferred tool for managing data and evaluating trends. Developers looking to build the next generation of business applications can accommodate those tendencies by integrating native spreadsheet support for Microsoft Excel workbooks.

Excel Worksheets vs Excel Workbooks

Although sometimes referred to interchangeably or described broadly as spreadsheets, there is a key distinction between an Excel worksheet and an Excel workbook. A worksheet consists of only one spreadsheet while a workbook contains multiple different spreadsheets separated by tabs.

The difference may not be very important when viewing or sharing XLSX files natively in Microsoft Excel, but it can create serious challenges when rendering those files in another application. Without some way of accurately rendering dynamic spreadsheet data, viewers are often forced to resort to a static print preview image. This process makes the file viewable, but also leaves it “flattened” because all interactive elements are removed from the spreadsheet cells.

If the workbook contains worksheets with linked data (that is, cell data from one sheet is affected by cell data from another sheet), it’s critical that a viewing solution preserves the dynamic aspects of the file. The advantage of a spreadsheet is that it can serve as a working document. Without the ability to interact with it, users might as well simply copy and paste the data into a text document.

Managing Excel Workbooks with PrizmDoc Cells

PrizmDoc Cells provides several options for managing Excel workbooks, making it easy to transition back and forth between XLSX format and web browser viewing. Once a proxy route is set up within the application to send API calls to the PrizmDoc Cells server, three different commands can be used to manage Excel workbooks.

Upload Workbook

This API call adds a new XLSX file for viewing and editing. When a document is uploaded to the system, the server assigns a unique workbook ID to it so it can be found and rendered in the application’s viewer in the future. After uploading a workbook, a new session can be created using the workbook ID for viewing and editing purposes. 

Download Workbook

When PrizmDoc Cells displays a spreadsheet, it renders the XLSX file itself, but it doesn’t make any alterations to that file. As each session makes edits to the workbook, those changes are associated with the document ID rather than the original XLSX file, which preserves the integrity of the original spreadsheet. At some point, however, those edits may need to be saved into a new Excel workbook. 

The download API call converts the current session document so it can be downloaded as an XLSX file. File availability can be set during the download process to control who will have access to the new workbook.

Delete Workbook

Old versions of workbooks often need to be deleted for security reasons, usually because they contain confidential data. Since the original XLSX file remains safely within application storage, there often isn’t much sense in retaining workbooks IDs that aren’t being used. The delete API call removes a workbook ID from the server. Once removed in this way, the workbook cannot be viewed, edited, or downloaded by PrizmDoc Cells.

Preserving Workbook Functionality

Since PrizmDoc Cells natively renders information contained in an XLSX file, it retains the dynamic elements that make spreadsheet workbooks so useful to organizations. Not only does it preserve proprietary business logic and formulas, but it also maintains the integrity of this information across multiple worksheets. Cell content can still be searched to quickly locate important text or data throughout the workbook.

For situations where proprietary formulas need to be protected, PrizmDoc Cells allows users to upload XLSX workbooks as values-only files, with all spreadsheet formulas removed. Also, any cells locked in an uploaded XLSX file will remain locked in PrizmDoc Cells to preserve workbook security.

True Spreadsheet Workbook Support for Your Applications

Many organizations continue to depend upon spreadsheet workbooks to manage their business. By providing feature-rich workbook support within their applications, developers can help them retain control over their proprietary spreadsheet formulas without sacrificing the functionality they expect from Excel. 

PrizmDoc Cells makes it easier than ever to share spreadsheet workbooks without having to rely upon Microsoft Excel dependencies. Shared XLSX files can remain safely within a secure application environment to prevent unauthorized downloads or troublesome version confusion. Get a first-hand look at how PrizmDoc Cells can enhance your application in our extensive online demo.

Barcode Xpress and ImageGear .NET.  Barcode Xpress is a leading barcode reading SDK. While it supports a variety of image formats, Barcode Xpress works with ImageGear to support even more obscure image formats. For example, Barcode Xpress does not support reading barcodes on PDFs. Combined with ImageGear, developers can support a myriad of image formats and PDFs. With Barcode Xpress & ImageGear working together, developers can integrate a barcode reader that can detect barcodes on almost any kind of document.

Barcode Xpress accepts images in multiple different object types, such as System.Drawing.Bitmap. Using the method ImGearFileFormats.ExportPageToBitmap we can easily take any image that ImageGear supports and export it to a System.Drawing.Bitmap object that we can then pass to Barcode Xpress. So, only a tiny amount of code is required to recognize barcodes with ImageGear .NET and Barcode Xpress. Below, we’ll show various ways to pass different types of images and documents to Barcode Xpress.

Image:

// Load the image into the page.
ImGearPage imGearPage = ImGearFileFormats.LoadPage(stream, 0);

// Export the image to a bitmap and pass that bitmap to Barcode Xpress
 Result[] results = barcodeXpress.reader.Analyze(ImGearFileFormats.ExportPageToBitmap(imGearPage));

PDF:

We need slightly more code for a PDF. First, we specify a page number when calling LoadPage. Second, we must dispose of the ImGearPage object after we’re done with it. 

// Load the specified page of the PDF as an ImGearPage object
ImGearPage imGearPDFPage = ImGearFileFormats.LoadPage(stream, pageNumber);

// Export the image to a bitmap and pass that bitmap to Barcode Xpress
Result[] results = barcodeXpress.reader.Analyze(ImGearFileFormats.ExportPageToBitmap(imGearPDFPage));

(imGearPDFPage as IDisposable).Dispose();

Now that we’ve explained the most important part, we’ll show you a simple console app that recognizes barcodes on a PDF using the method above. 

The code below assumes you’ve installed an evaluation or development license for both Barcode Xpress and ImageGear .NET.

using System;
using System.IO;
using Accusoft.BarcodeXpressSdk;
using ImageGear.Core;
using ImageGear.Evaluation;
using ImageGear.Formats;
using ImageGear.Formats.PDF;

namespace BXandIGDotNet
{
	class Program
	{
    	static int pageNumber = 0;
    	static string fileName = @"Path/To/Your/PDF..pdf";
    	static void Main(string[] args)
    	{
        	// Initialize evaluation license.
        	ImGearEvaluationManager.Initialize();

        	// Initialize common formats.
        	ImGearCommonFormats.Initialize();
        	// Add support for PDF and PS files.
        	ImGearFileFormats.Filters.Insert(0, ImGearPDF.CreatePDFFormat());
        	ImGearFileFormats.Filters.Insert(0, ImGearPDF.CreatePSFormat());
        	ImGearPDF.Initialize();

        	using (FileStream stream = new FileStream(fileName, FileMode.Open, FileAccess.Read, FileShare.Read))
        	using (BarcodeXpress barcodeXpress = new BarcodeXpress())
        	{
            	// Load the specified page of the PDF as an ImGearPage object
            	ImGearPage imGearPDFPage = ImGearFileFormats.LoadPage(stream, pageNumber);

            	// Export the image to a bitmap and pass that bitmap to Barcode Xpress
            	Result[] results = barcodeXpress.reader.Analyze(ImGearFileFormats.ExportPageToBitmap(imGearPDFPage));

            	(imGearPDFPage as IDisposable).Dispose();

            	// Print the values of every barcode detected.
            	for (int i = 0; i < results.Length; i++)
            	{
                	Console.WriteLine("#" + i.ToString() + " Value: " + results[i].BarcodeValue);
            	}
            	Console.ReadKey();
        	}
    	}
	}
}

Using Barcode Xpress and ImageGear in Other Languages & Linux

You can also use Barcode Xpress and ImageGear together outside of the .NET framework. Barcode Xpress supports several different programming languages and frameworks including .NET Core, Java, NodeJS, Python, C, and C++. All of which can be used on Linux. 

ImageGear for C/C++ also supports Linux. Barcode Xpress Linux, which is a C/C++ library, ships with a sample called “ReadBarcodesIG”, that shows how to integrate Barcode Xpress Linux and ImageGear for C/C++. You can find the sample code after downloading our SDK here! For more information on Barcode Xpress, visit our Developer Resources page on the website. In addition, you can also find more information about ImageGear .NET on its respective Developer Resources page as well.

Most software developers turn to third party integrations like Accusoft’s PrizmDoc to incorporate document processing capabilities into their applications. Since developers are frequently pressed for time and resources, it doesn’t make sense to build document lifecycle features from scratch when they can easily deploy a proven, scalable solution that provides all the tools they need. An API-based integration like PrizmDoc can quickly add industry-leading viewing, editing, collaboration, conversion, and assembly features to an application, which allows developers to focus on other features that will help their software stand out from competitors.

Pros and Cons of Server-Side Viewing

All that document processing power has to come from somewhere, and in the case of solutions like PrizmDoc, most processing is handled by a dedicated server. The server may be self-hosted on the developer’s local infrastructure, a dedicated private cloud, or a public cloud that’s shared by multiple customers.

There are plenty of advantages to this model. Scalable infrastructure is available for the heaviest document processing workloads, but customers only have to pay for the resources they actually use. A dedicated server also makes it easy for applications to manage document storage and avoid version confusion.

Server-side resources can also pose challenges for some applications. If the server is constantly being used to prepare and render documents for viewing, customers may find themselves utilizing more processing resources than expected. Scaling viewing capabilities for multiple users can increase resource usage because each session places additional processing requirements on the server, especially if users need to make annotations, redactions, or other alterations to files.

Viewing multiple, lengthy files server-side can also impact performance. PrizmDoc’s HTML5 viewer, for instance, converts and renders documents in SVG format. While this format offers outstanding quality and flexibility, load time may take longer and it also takes up server storage space.

Introducing PrizmDoc Hybrid Viewing

The new PrizmDoc Hybrid Viewing feature solves these challenges by offloading the processing work for viewing in PDF format to the end user’s device. This is a hybrid approach between server-side processing and client-side processing, with all of the viewing capabilities handled by the client-side device. This drastically reduces the server resources needed to prepare files for viewing, which translates into cost saving and improved performance. Since all viewing is handled by the browser on the client-side device, Hybrid Viewing offers much greater responsiveness for a better overall user experience.

For files not already in PDF format users can take advantage of the new viewing package which converts any file format to PDF. This not only allows documents to be viewed more quickly in the future, but also reduces server load and storage requirements.

5 Key Benefits of PrizmDoc Hybrid Viewing

The Hybrid Viewing feature works within PrizmDoc’s existing viewing package infrastructure, making it a simple and streamlined solution for both new and existing customers. Shifting viewing processing from the server to client-side devices provides applications with several important benefits.

1. Cost Savings

Transferring the processing work required for document viewing to an end user’s device reduces server workloads. Since customers pay for the server resources their applications utilize, minimizing server requirements for viewing can deliver significant cost savings over time.

2. Better Resource Management

All file types can be used with this new Hybrid Viewing feature. The new PDF viewing package pre-converts all file types into PDF only, rather than creating SVG files with large amounts of data. This saves both processing time and storage resources. Developers can take advantage of this flexibility and resource savings to implement additional application features that leverage PrizmDoc’s capabilities.

3. Increased Productivity

Shifting document viewing workloads to client-side devices allows applications to process, view, and manage multiple documents faster. This helps end users to do their jobs more efficiently and get greater value out of their applications.

4. Enhanced Performance

Hybrid viewing not only requires fewer resources, but files can be viewed and manipulated faster with enhanced responsiveness. For applications that need to provide editing features such as annotations, offloading processing to client-side devices minimizes load times and lag for a better overall user experience.

5. Scalable Document Viewing

By handling document viewing capabilities on local devices instead of the server, scaling capacity becomes far less resource intensive. File conversion only needs to be performed once, so adding more users doesn’t increase the overall server workload.

What Hybrid Viewing Means for PrizmDoc Users

The new Hybrid Viewing feature allows PrizmDoc users to get more out of their integration than ever before. For customers who have long relied on desktop-based PDF.js viewers due to concerns about server workload or performance, the Hybrid Viewing feature provides a localized viewing solution that streamlines their tech stack and leverages the full capabilities of PrizmDoc. By minimizing server requirements, developers can unlock the potential of their applications to scale their document lifecycle features without worrying of runaway costs.

Hybrid Viewing is available for PrizmDoc Server v13.15 or greater and can be used for self-hosted, private cloud-hosted, or public cloud-hosted deployments. To learn more about how it can provide the flexibility your application needs to scale with user demands, talk to one of our PrizmDoc specialists today.