Technical FAQs

What file formats does PrizmDoc Viewer currently support?

Please refer to our latest documentation for the most up-to-date list of supported file formats:

• Supported File Formats

For documentation on older versions of PrizmDoc Viewer, please see our documentation archive.

The logging for ImageGear C & C++ Deployment Packaging Wizard (DPW) is showing different output for some components since v19.3, why is this?

In ImageGear C & C++ v19.2 and prior, the DPW had additional logging information for the ARTX component in its deployment.log:

Deploying an application that uses the ARTXGUI library of ImageGear
ARTX Component requires the following merge modules to be installed:

Microsoft_VC90_CRT_x86_x64.msm

Microsoft_VC90_MFC_x86_x64.msm

But since v19.3, the logs are no longer telling me to install these modules. Is this a mistake, or are they no longer necessary?

This was an intentional change on our end, and the Deployment Packaging Wizard (DPW) is working as intended. We made some updates to the DPW in the latest release; one update is that the CRM requirements for CORE (which is required in every project) now also covers the ARTX component. If the DPW is not saying you need additional components to use the ARTX component, then you’ll be fine.

My document appears to be loading incorrectly. Are there any troubleshooting steps that I can take?

First, confirm that this is a document-specific issue by trying other documents of the same file type or documents of the same file type with similar size characteristics and content.

Second, if the document is a Microsoft Office document and you are using LibreOffice as your backend renderer, you can compare the way that the document displays in PrizmDoc against the way the document displays in the copy of LibreOffice shipped with PrizmDoc (C:\Prizm\libreoffice\program\soffice.exe on Windows, /usr/share/prizm/libreoffice/program/soffice on Linux). To inquire about the Microsoft Office renderer plugin, which may resolve office document rendering issues, send an email to sales@accusoft.com.

Third, reach out to a support technician at support@accusoft.com, as they will be able to quickly test how the document renders in the latest version of PrizmDoc, and consult the product engineers in the event that there is a rendering issue.

Have the following information handy, as it will help the support technician better assist you:

• What version of PrizmDoc are you using?

• What operating system are you using?

  • If Windows, are you using the LibreOffice or Microsoft Office backend renderer?

• A PDF export or a screenshot of what you see in PrizmDoc, compared to a screenshot of how the document looks in its native file type viewer.

• Log files that include the processing of the incorrectly loading document.

• Any changes that you may have made to the PrizmDoc configuration files.

I need to store a unique ID with each of my marks. Is the ID returned by Mark.GetID() unique?

The ID generated by Mark.GetID() is only unique for that instance of the viewing session (for example, if you refresh the page, the counter for mark IDs will reset to 1).

If you are saving your marks to markup layers using the SaveMarkupLayers() method, then each mark will have a unique ID generated which will be stored in the “uid” key in the markup layer JSON.

If you are saving your marks as XML, using the SaveMarks() method, then each mark’s unique ID will be stored in the key “nodeId”.

If you want to generate your own unique ID for your marks, you can include the code below in your viewer.js to generate a UUID. A UUID contains 122 randomly generated bits so you shouldn’t need to worry about any duplicate IDs:

    function uuidv4() {
      return ([1e7]+-1e3+-4e3+-8e3+-1e11).replace(/[018]/g, c =>
        (c ^ crypto.getRandomValues(new Uint8Array(1))[0] & 15 >> c / 4).toString(16)
      )
    }

You can store this UID in the marks data using Mark.SetData("ID", uuidv4());.

You can then use Mark.GetData("ID"); to retrieve the ID at a later time.

I am trying to perform OCR on a PDF created from a scanned document. I need to rasterize the PDF page before importing the page into the recognition engine. When rasterizing the PDF page I want to set the bit depth of the generated page to be equal to the bit depth of the embedded image so I may use better compression methods for 1-bit and 8-bit images.

ImGearPDFPage.DIB.BitDepth will always return 24 for the bit depth of a PDF. Is there a way to detect the bit depth based on the PDF’s embedded content?

To do this:

1. Use the ImGearPDFPage.GetContent() function to get the elements stored in the PDF page.
2. Then loop through these elements and check if they are of the type ImGearPDEImage.
3. Convert the image to an ImGearPage and find it’s bit depth.
4. Use the highest bit depth detected from the images as the bit depth when rasterizing the page.

The code below demonstrates how to do detect the bit depth of a PDF page for all pages in a PDF document, perform OCR, and save the output while using compression.

private static void Recognize(ImGearRecognition engine, string sourceFile, ImGearPDFDocument doc)
    {
        using (ImGearPDFDocument outDoc = new ImGearPDFDocument())
        {
            // Import pages
            foreach (ImGearPDFPage pdfPage in doc.Pages)
            {
                int highestBitDepth = 0;
                ImGearPDEContent pdeContent = pdfPage.GetContent();
                int contentLength = pdeContent.ElementCount;
                for (int i = 0; i < contentLength; i++)
                {
                    ImGearPDEElement el = pdeContent.GetElement(i);
                    if (el is ImGearPDEImage)
                    {
                        //create an imGearPage from the embedded image and find its bit depth
                        int bitDepth = (el as ImGearPDEImage).ToImGearPage().DIB.BitDepth; 
                        if (bitDepth > highestBitDepth)
                        {
                            highestBitDepth = bitDepth;
                        }
                    }
                }
                if(highestBitDepth == 0)
                {
                    //if no images found in document or the images are embedded deeper in containers we set to a default bitDepth of 24 to be safe
                    highestBitDepth = 24;
                }
                ImGearRasterPage rasterPage = pdfPage.Rasterize(highestBitDepth, 200, 200);
                using (ImGearRecPage recogPage = engine.ImportPage(rasterPage))
                {
                    recogPage.Image.Preprocess();
                    recogPage.Recognize();
                    ImGearRecPDFOutputOptions options = new ImGearRecPDFOutputOptions() { VisibleImage = true, VisibleText = false, OptimizeForPdfa = true, ImageCompression = ImGearCompressions.AUTO, UseUnicodeText = false };
                    recogPage.CreatePDFPage(outDoc, options);
                }
            }
            outDoc.SaveCompressed(sourceFile + ".result.pdf");
        }
    }

For the compression type, I would recommend setting it to AUTO. AUTO will set the compression type depending on the image’s bit depth. The compression types that AUTO uses for each bit depth are: 

• 1 Bit Per Pixel – ImGearCompressions.CCITT_G4
• 8 Bits Per Pixel – ImGearCompressions.DEFLATE
• 24 Bits Per Pixel – ImGearCompressions.JPEG

Disclaimer: This may not work for all PDF documents due to some PDF’s structure. If you’re unfamiliar with how PDF content is structured, we have an explanation in our documentation. The above implementation of this only checks one layer into the PDF, so if there were containers that had images embedded in them, then it will not detect them.

However, this should work for documents created by scanners, as the scanned image should be embedded in the first PDF layer. If you have more complex documents, you could write a recursive function that goes through the layers of the PDF to find the images.

The above code will set the bit depth to 24 if it wasn’t able to detect any images in the first layer, just to be on the safe side.

We are converting emails into PDFs using PrizmDoc. When the PDF is viewed in PrizmDoc, if you hover over the names in the email header, you see a mailto link that provides the email address.

Is there a way to remove those links during the conversion process? We wish to ensure there are no email addresses present in the PDFs.

To work around this issue, you can first convert the email (MSG) to a TIFF file. This will remove the links and just keep the name of the email recipient. Then convert the TIFF file to a searchable PDF.

This workaround requires that your PrizmDoc license has the OCR option enabled to create the searchable PDF. If you do not need to make the text searchable, then you can just convert the TIFF to a PDF.

We are interested to know how well the cloud offering
scales. For example, can we process thousands of transactions per second? Is there a limit to the number of transactions that we can use
concurrently?

The limitation will vary depending on the size of the documents and the type of work being performed on them.

PrizmDoc Cloud utilizes AWS servers to scale our services as demand increases, and we do currently rate limit total requests which should not exceed 100 requests within an eight second window. The window is rechecked every four seconds to determine if the rate limit is still in excess.

Where is your PrizmDoc Cloud environment hosted? Is your cloud solution running on AWS?

Our PrizmDoc Cloud environment is hosted on Amazon Web Services (AWS) running in us-east-1 (Virginia).

I know the coordinates and dimensions of the content I would like to highlight, but the highlight annotation only works on text. Is there a way to create an annotation that highlights a specific area of a document?

The best way to do this would be to create a yellow rectangle annotation with 50% opacity (these are the same default values used by the text highlight annotation). The code below demonstrates how to do this in the viewer:

//Create a new rectangle annotation
var rectangleMark = viewer.viewerControl.addMark(1,  PCCViewer.Mark.Type.RectangleAnnotation);
//Set the coordinates and dimensions of the annotation
rectangleMark.setRectangle({x: 100, y:  100,  width : 200, height: 200});
//Set fillcolor to yellow
rectangleMark.setFillColor("#FFFF00");
//Remove the border
rectangleMark.setBorderColor("transparent");
//Set opacity to 50%
rectangleMark.setOpacity(127);

In the PrizmDoc Viewer, what are the two different ways to load annotation layers?

PrizmDoc has two options for loading annotations, the “My Annotations” pane and the “Annotations for Review” pane.

The “My Annotations” pane is used to load a single annotation layer for editing. You can add, delete, or make changes to annotations and then save those changes using the “My Annotations” pane.

The “Annotations for Review” pane is used for viewing annotations. You can load as many annotation layers for viewing as you would like. You cannot interact with annotations loaded in this way, but you are able to make comments on them. You can toggle between any of these layers to hide them. You can also merge these annotations to the currently loaded annotation layer from “My Annotations”.

For more information see our documentation here: https://help.accusoft.com/PrizmDoc/latest/HTML/Annotation_Layers.html

Today we noticed that when trying to start the Prizm service, it hangs for a few minutes and then displays an error: “Service Failed to start in a timely fashion”, and the service remains stopped.

The watchdog.console.log shows “DieError: Configuration error, failed to parse the configuration file”.

How can we fix this?

This issue typically happens when the server was not shut down properly, and some of the PrizmDoc files have become corrupted.

To resolve the issue, take the following steps:

1. Make a backup of your PrizmDoc configuration files.
2. Uninstall and then re-install PrizmDoc.
3. Verify the service is running.
4. Stop the service, restore backed-up configuration files.
5. Restart Prizm service.

When printing in PrizmDoc, the bottom of my document is being cut off. Why is this happening?

When I download the document as PDF, I do not lose parts of the document. However, if I print the document to PDF, I lose some data off the very bottom (maybe an inch or so).

In PrizmDoc, the page is to "fit to width" onto the paper by design. The bottom of the page will be cut off in cases where the length of the page extends further than the length of the paper. If you’re printing with Letter size paper (the default), it presumes a document that measures 8.50 by 11.00 inches. Suppose your document measures 8.50 x 13.00 inches. That additional 2 inches will be cut off during printing. This is why you may lose parts of the document while printing, but not if you download the document since it’s downloading the document as-is.  

To prevent this from happening, select a paper size large enough for your document (in the viewer print dialog and the system print dialog). Using the previous 8.50 x 13.00 inch example, you can select "Legal" size paper, which measures 8.50 x 14.00 inches, and would be long enough to support that document.

You could also modify your viewer to add a custom paper size if this fits your use case. Below is some sample code demonstrating this in our Viewer sample. You would need to enter your own custom paper sizes.

https://www.accusoft.com/code-examples/printing-custom-paper-sizes/

Changes to printTemplate.html:

    /*custom */
    .portrait .custom.page { width: 11in; height: 11in; margin: 0 auto !important; }
    .portrait .custom.pageIE { width: 9.5in; height: 9.5in; margin: 0 auto !important; }
    .portrait .custom.pageSafari { width: 8.9in; height: 8.9in; margin: 0 auto !important; }
    .portrait .custom.nomargins { width: 11in !important; height: 11in !important; }
    /* even without margins, Safari enforces the printer's non-printable area */
    .portrait .custom.nomargins.pageSafari { width: 9.32in !important; height: 9.32in !important; }
    
    .landscape .custom.page { height: 11in; width: 11in; margin: 0 auto !important; }
    .landscape .custom.pageIE { height: 9.05in; width: 9.05in; margin: 0 auto !important; }
    .landscape .custom.pageSafari { height: 8.4in; width: 8.4in; margin: 0 auto !important; }
    .landscape .custom.nomargins { height: 11in !important; width: 11in !important; }
    .landscape .custom.nomargins.pageSafari { height: 9.32in !important; width: 9.32in !important; }
    /*custom end*/

Changes to printOverlayTemplate.html (last line "Custom" is the only change):

    <select data-pcc-select="paperSize" class="pcc-print-select">
        <!-- US and International-->
        <option value="letter"><%= paperSizes.letter %></option>
        <option value="legal"><%= paperSizes.legal %></option>
        <option value="tabloid"><%= paperSizes.tabloid %></option>
        <option value="foolscap"><%= paperSizes.foolscap %></option>
        <!-- A formats-->
        <option value="a3"><%= paperSizes.a3 %></option>
        <option value="a4"><%= paperSizes.a4 %></option>
        <option value="a5"><%= paperSizes.a5 %></option>
        <!-- Architectural-->
        <option value="a6"><%= paperSizes.a6 %></option>
        <option value="a"><%= paperSizes.a %></option>
        <option value="b"><%= paperSizes.b %></option>
        <option value="c"><%= paperSizes.c %></option>
        <option value="d"><%= paperSizes.d %></option>
        <option value="e"><%= paperSizes.e %></option>
        <option value="e1"><%= paperSizes.e1 %></option>
            
        <option value="custom">Custom</option>
    </select>

Additionally, if you would like to change the default selected page size you can add selected to it as follows:

<option value=\"a4\" selected><%= paperSizes.a4 %></option>