Technical FAQs for "PrizmDoc"

When running PrizmDoc on multiple servers using self-hosted cloud licensing, why is the service randomly stopping on one server but not another?

When using cloud licenses, we require that the server running PrizmDoc has internet access. The server needs to communicate with the Amazon S3 bucket used for the license, and also to verify you are within the CPU core count you are licensed for.

If you are seeing the Prizm service stop on certain systems with this type of
license, you can verify the following:

1. For all servers using this license, verify the core count on each server and then add them up. If the total number of cores exceeds what you are licensed for, then the Prizm service will shut down on the server where the service was started first after it checks the S3 bucket and determines the core count has been exceeded.
2. If the server’s DNS resolution becomes unstable and the server is unable to resolve URLs, the Prizm service on that server will be unable to verify the license on the S3 bucket, which will cause the Prizm service to stop.
3. Verify that the server has the appropriate rights to the S3 bucket outlined in the following FAQ: What specific rights are required on an AWS S3 bucket for PrizmDoc Cloud licensing to work?

With PrizmDoc, how can I hide a predefined search if there are no results?

The predefined search option does not support that functionality, but you can instead perform a server-side search, and then activate the search panel if there are results to show:

var viewer;
var viewingSessionId = <%= viewingSessionId %>;

var fixedSearchTerm = "the";
var pasUrl = "/pas";

var viewerReady = false;
var searchReady = false;
var searchDisplayed = false;

function displaySearchIfNeeded() {
    // The search is only displayed once the viewer is ready, and once our preliminary server-side search comes back positive.
    if (viewerReady && searchReady && !searchDisplayed) {
        searchDisplayed = true;

        $("[data-pcc-search=\"input\"]").val(fixedSearchTerm);
        $("[data-pcc-search=\"submit\"]").click();
    }
}

function sendSearchPost() {
    $.ajax({
        "method": "POST",
        "url": pasUrl + "/v2/viewingSessions/" + viewingSessionId + "/searchTasks",
        "data": JSON.stringify({
            "input": {
                "searchTerms": [
                    {
                        "type": "simple",
                        "pattern": fixedSearchTerm,
                        "caseSensitive": false,
                        "termId": "0"
                    }
                ]
            }
        }),
        "contentType": "application/json",
        "success": function(response) {
            $.ajax({
                "url": pasUrl + "/v2/searchTasks/" + response["processId"] + "/results?limit=1",
                "success": function(response) {
                    if (response.results.length !== 0) {
                        searchReady = true;

                        displaySearchIfNeeded();
                    }
                },
            });
        },
        "error": function(jqXHR, textStatus, errorThrown) {
            if (jqXHR.status === 480) {
                setTimeout(sendSearchPost, 2000);
            }
        }
    });
};

setTimeout(sendSearchPost, 500);

$(document).ready(function() {
    // Since we are no longer restricted to a predefined search, we can load the viewer ASAP.
    viewer = $("#viewer").pccViewer({
        "documentID": viewingSessionId,
        "imageHandlerUrl": "/pas",
        "language": viewerCustomizations.languages["en-US"],
        "template": viewerCustomizations.template,
        "icons": viewerCustomizations.icons
    });

    viewer.viewerControl.on("ViewerReady", function(event) {
        viewerReady = true;

        displaySearchIfNeeded();
    });
});

When viewing .csv files in PrizmDoc Viewer, the dates in the CSV file are in UK format (DD/MM/YYYY). However, if the DD is lower than 13 it is converted to US date format (MM/DD/YYYY).

Workaround:

The suggested workaround is to use Excel files instead of CSV to avoid this situation. Excel file format stores date/time format in the file.

Issue:

This is a bug in the MS Excel COM Interop that is being used by the product (MsOfficeConverter). Here is the related Excel bug: https://social.msdn.microsoft.com/Forums/vstudio/en-US/82248560-dabd-4c90-b1e2-793b2f32b257/excel-bug-handling-dates-in-csv-files-using-microsoftofficeinteropexcel?forum=exceldev

Problem description:

When using MS Excel Interop to open CSV files, all date/times there are being interpreted with “en-US” locale, regardless of actual system locale. Here is the description from the bug link above:

Excel interpreting dates when its reads csv files via .NET Interop. It is not a excel formatting issue per say. When excel accesses information such as dates (which are stored as numbers in memory to support arithmetic operations) from text files, it has to convert the date from textual representation (within the csv file, such as 2012-09-12) to the equivalent number in Excel memory (e.g. 41164 which represents 2012-09-12). When we use Interop to access this number in memory, many are interpreted incorrectly – swapping days with months and vice versa. This is a bug, as Excel is not abiding by the system culture on interpreting local date formats.

When looking at the configuration files for both PAS (pcc.win.yml, pcc.nix.yml) and PrizmDoc Server (prizm-services-config.yml), there appear to be similar settings for Viewing Session timeouts: defaults.viewingSessionTimeout (PAS) and viewing.sessionLifetime (Server). What is the difference between the two?

The difference is as follows:

PAS

defaults.viewingSessionTimeout

This setting is used when the viewing session POST requests use source.type="viewingPackage".

Prizm Server

viewing.sessionLifetime

This setting is used for all other viewing session POST requests.

When loading PDF documents into PrizmDoc that contain embedded highlights, rather than appearing translucent, the highlights are appearing opaque and are covering the underlying text. Why is this happening?

Prior to version 13.4 of PrizmDoc, this was occurring due to limitations in web browsers. The SVG attribute comp-op="multiply" was not widely supported in modern browsers.

With PrizmDoc version 13.4, the way highlights were rendered was changed to resolve this issue.

When printing non-standard size raster images with PrizmDoc they can sometimes become cutoff if too tall or wide. How can I correctly print a non-standard size raster image with PrizmDoc?

(This explanation is done for a tall portrait image, but can be altered to work for a wide landscape image by flipping the width and height.)

To do this, you have to add a custom paper size to viewerCustomization.js and specify a smaller width so that there is enough room to fit the height of the image on a single page.

To find the correct width value so that the image will fit on a single page, you will need to do some math. In this example, we’ll use an image that is 1305×2823. In this case, the width is 46.2% of the height. If you want to print onto 8.5×11 inch paper, then the width you want to set for your new custom paper size is 11*0.462, which comes out to 5.082.

So now that you have the width, you need to create the new custom paper size. In viewerCustomization.js in the templates section, find the "print" template and add the following code where the other printing paper sizes are located.

/*custom */
.portrait .custom.page { width: 5.082in; 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: 5.082in; 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*/

As you can see, the width for .portrait .custom.page was set to 5.082in, and the height set to 11in. This will scale the 1305×2823 image to fit on a single 8.5×11 page when printing. By flipping the values and setting them in .landscape you would be able to print a 2823×1305 image on a single landscape page. (Just to note, I only edited the values for .custom.page for portrait and landscape. The others would most likely need to be changed.)

Next you need to add an option for your new paper size to the "paperSize" selection tag in the "printOverlay" section of templates in viewerCustomization.js. Your select tag should end up looking something like this:

<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>

The new print option should now appear in the PrizmDoc print settings when selecting a paper size, and it should print the image on a single page.

One thing to note is that you will have to do this for each differently sized image. If you are unsure of the size of uploaded documents, this solution will most likely not be usable.

After searching a document, an error icon appears in the search results panel. Clicking on it displays the following error message: “x page(s) cannot be searched.” Why does this occur and how can I find out which specific pages couldn’t be searched?

When the PrizmDoc Viewer text-service cannot find any text for a given page in the document, it provides an array of all the pages without text in the response from searchTask results.

In short, the document is fine and simply contains pages without text. If you look at the pagesWithoutText array contained within the response data from searchTasks, you’ll see something like this:

[0, 1, 7, 17, 43, 45, 65, 67, 77, 79,…]

The values reported are pages that do not contain any text but instead are either blank or contain an image. This data can then be used to inform the user of how many pages are not searchable.

Can I use all of the features and configuration options in PrizmDoc Cloud-Hosted that I can in PrizmDoc Self-Hosted?

Currently, PrizmDoc Cloud does not allow for editing the server central configuration parameters, but the defaults have been set to allow for more complex documents that might otherwise fail in order to account for the lack of ability to modify these options.

After restarting the Prizm Services, you may notice that the http://localhost:18681/admin status page shows a status of “unhealthy” and in the Internal Services section, the mongo-manager-service is showing a clock, and the text-service is showing a red x.

How can this be fixed?

Reason:

This will typically occur when the mongo-manager-service detects an unclean shutdown and the cache gets corrupted.

How to Verify:

You can do a search in the C:\Prizm\logs\mongod.log file on Windows or the /usr/share/prizm/logs/mongod.log file on Linux for the word "unclean" and you may find the following error:

Detected unclean shutdown -
C:\Prizm\cache\mongo-manager-service\data\mongod.lock is not empty.

Resolution:

1. Stop the Prizm Services.

2. For PrizmDoc 13.3 and above, clear out all subfolders under prizm\cache (leave the prizm\cache folder).

3. For PrizmDoc 13.2 and prior, clear out all files and subfolders under C:\Prizm\services\mongo-manager-service\bin\mongodb\data

4. Start the Prizm Services.

Currently we are using PAS for viewing packages and it is pointed to our Accusoft Cloud subscription API key. PAS is installed locally and we store the viewing package artifacts in our S3 bucket. We are using 600 GB of storage on S3 for the viewing package artifacts we already have converted.

We would like to start using Accusoft’s Cloud PAS API to create viewing packages and no longer wish to host our own PAS and have the following questions:

1. Is there a way we can migrate our current artifacts from our S3 bucket to Accusoft’s S3 bucket?

2. Is there an additional charge for storing the artifacts at Accusoft?

3. Is there a way to point the Cloud PAS to our existing S3 bucket?

Q: Is there a way we can migrate our current artifacts from our S3 bucket to Accusoft’s S3 bucket?

A: We do not currently offer an API for directly importing your existing viewing packages. However, you can re-create your viewing packages in PrizmDoc Cloud using the original source document.

Q: Is there an additional charge for storing the artifacts at Accusoft?

A: At this time there is no additional charge. However, this is
subject to change.

Q: Is there a way to point the Cloud PAS to our existing S3 bucket?

A: There is currently no setting available to configure your PrizmDoc Cloud account to use an S3 bucket which you own. If you use PrizmDoc Cloud, the storage is managed by Accusoft. If you need to own and manage the storage yourself, you’ll want to use your own Self-Hosted PAS.

I have just installed PrizmDoc to my Windows server. When checking the status using http://localhost:18681/admin, the service is showing in a starting phase and ms-office-conversion-service is showing a clock icon, but it never starts.

What are some reasons as to why this might occur?

This can happen if your PrizmDoc license has the MSO feature enabled and you do not have Microsoft Office 2013 or 2016 installed, or Office 2013 or 2016 is not activated.

To fix this issue you can either:

• Install Microsoft Office 2013 or 2016, activate it, and reboot the server.

Or:

• Switch PrizmDoc to use LibreOffice until you are able to install Microsoft Office by modifying C:\Prizm\prizm-serivices-config.yml and updating the line:

  #fidelity.msOfficeDocumentsRenderer: auto
  

  to:

  fidelity.msOfficeDocumentsRenderer: libreoffice
  

I changed the value of viewingSessionTimeout