Technical FAQs for "PrizmDoc"


Does viewing HTML in PrizmDoc Viewer allow JavaScript execution or local file access? Can PrizmDoc Viewer block externally-referenced content from being rendered?


When viewing HTML in PrizmDoc, JavaScript and local file access are disabled.

Additionally, you may configure the security.htmlRendering.blockExternalContent setting found in PrizmDoc’s Central Configuration file. When rendering any source document which uses HTML content, this setting controls whether or not externally-referenced content, such as images and iframes, will be blocked. This option affects any source document file type which uses HTML, including HTML, EML, and MSG.


We just installed the PrizmDoc client and noticed that when we run Prizm Application Services, the service states that it is started, but it is not listening on 3000, and there are no logs written to the Prizm\logs\pas folder. What might the issue be?


A possible reason for this issue can be due to the Windows system environment variable called PATHEXT. By default, .COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC are configured.

What this variable does is allow commands to be executed without needing to add the extension to them.

For example, PM2, which runs with PAS, has a file extension of .CMD, so when executing PM2 in a command line you just need to type PM2 instead of the full name PM2.CMD.

If .CMD is not in the PATHEXT environment variable, then just typing PM2 would return a command not found error, and you would need to use the full PM2.CMD for it to work.

To fix the issue, ensure the following:

  1. Open Control Panel > All Control Panel Items > System
  2. Select Advanced System Settings
  3. Select Environment Variables
  4. Under System Variables double-click PATHEXT
  5. Add to the end of the current string
  6. Restart Prizm Application Services

We are adding files to the viewing session with HttpWebRequests. We noticed with larger files the response is:

(413) Request Entity Too Large. -  at System.Net.HttpWebRequest.GetResponse(). 

What could be the cause?   


A 413 request entity too large error occurs when a request made from a client is too large to be processed by the web server. If your web server is setting a particular HTTP request size limit, clients may come across a 413 request entity too large response. An example request that may cause this error would be if a client was trying to upload a large file to the server (e.g., a large media file).

Depending on which web server you use, implement the necessary changes described below to configure your web server’s maximum HTTP request size allowance. Below are some suggestions for popular Web Servers:

For Nginx users:

The directive that determines the allowable HTTP request size is client_max_body_size. This directive can be defined in your nginx.conf file located at /etc/nginx/nginx.conf

For Apache users:

The directive is LimitRequestBody which can be defined in your http.conf file or in an .htaccess file.

For IIS users:

  1. Open Internet Information Services (IIS) Manager.
  2. In the Connections pane, go to the connection, site, application, or directory for which you want to modify your request filtering settings.
  3. In the Home pane, double-click Request Filtering.
  4. Click Edit Feature Settings in the Actions pane.

When installing PrizmDoc, we specified the wrong user ID and password for the 3 PrizmDoc services. Can we safely change them to another account?


It is possible to change the Login User account on the three PrizmDoc services: Prizm, PrizmDemo, and Prizm Application Services.

You will need to ensure the user id you use is in the local administrators group on the server, as well as a part of the Login As a Service rights in the machine’s local security policy.

To verify the user ID is added to the Local Administrators group:

  • Right-click the Windows Logo, select Run, and enter compmgmt.msc
  • In Computer Management expand Local Users and Groups
  • Under Local Users and Groups select Groups
  • Double-click Administrators group in the right panel
  • Verify the User ID is listed under Members

To verify the user Id has “Log on as a Service” rights in the Local Security Policy:

  • Right-click the Windows Logo, select Run, and enter secpol.msc
  • User Security Settings, expand Local Polices, and User Rights Assignment
  • In the right panel, double-click Log on as a service
  • Verify the user ID is listed, and if not, click on Add User or Group to add

Changing the service “Log on As” user id:

  • Right-click the Windows Logo, select Run, and enter services.msc
  • Find a service called Prizm and double-click on it
  • Click on Log On tab and click Browse to select new user id
  • Enter the Password for the new account and then enter Confirm Password
  • Restart the service
  • Repeat the above steps for PrizmDemo and Prizm Application Services

We entered our S3 bucket name in the customer portal, but used a capital letter for the first character; however, the S3 bucket name is all lowercase in AWS (Amazon Web Services).
Will this cause an issue with starting the service?


Yes, the bucket name is case-sensitive and must be entered exactly the same as the S3 bucket is named in AWS (Amazon Web Services).

AWS recommends you do not use uppercase letters in your bucket name.

If you made the first character of the name uppercase in the Accusoft Customer Portal, then the service will fail to start.

You will need to contact your Account Manager or Accusoft Technical Support to have the license re-created so that you can re-enter the S3 bucket name properly.


Sometimes, when redacting an Office or PDF document, redactions drawn over certain content (such as an image or a logo) appears to get burned on other occurrences of the image on other pages. Why does this happen?


The reason why the duplicate redactions are occurring is because the images are shared images. In PrizmDoc, when a change is made to one instance of the shared image, it gets applied to every other instance. Per engineering, this is to mimic the behavior of Adobe Acrobat.

There currently exists a feature request to allow shared images to be treated as individual images so that they could be redacted separately:


We are currently using PrizmDoc Cloud licensing. After applying our cloud license, the Prizm services started and show healthy, however, I see “CloudLicenseValidationFailed” errors in the PccErrors.log file. Is this normal, and do I have to worry about Prizm functionality?


Currently the licensing messages referencing “CloudLicenseValidationFailed” in PccErrors.log are a false positive and should not be taken as an issue with PrizmDoc Cloud licensing.
The more accurate way to check whether the license has been validated successfully would be to use watchdog.log and look for “Cloud License Validation” – “isValid”:true which indicates that the license is valid.

The issue regarding that error in pccerrors.log is in our product backlog to consider addressing in a future release, but it is not yet prioritized on our roadmap.


We have just applied the solution name and key for our cloud license, however, when trying to start the Prizm service, it fails to start.
What could be causing this issue?


There are a few reasons why this would occur:

  1. The server does not have internet access. Internet access is required for cloud licensing to connect to an S3 bucket.
  2. The server does not have proper rights to access the S3 bucket configured. Please verify the rights to the S3 bucket. Information can be found here:
  3. Verify the solution name is spelled properly. The solution name is case-sensitive.
  4. Verify that the name of the S3 bucket entered in the customer portal matches your actual S3 bucket name. The S3 bucket name is case-sensitive.

We have been noticing in our PrizmDoc environment that the viewer seems to take longer and longer to view documents over time. After a few days, we restart the Prizm services, and the Viewer processes faster. What might be the reason for this issue?


This issue is typically caused by a change in the core count of the server after PrizmDoc has been installed. Specifically, the non-interactive heap size will not automatically update if the core count is changed after PrizmDoc has been installed. We update this value during install.

If you have made changes to the core count of the server after installation, please see the following page for correlation between the non-interactive heap size and the CPU cores count:

The reason the non-interactive heap size matters here is because it affects performance of the Office and HTML conversion services, and the symptom of insufficient non-interactive heap size is soffice.bin crashing.


I am integrating PrizmDoc using just the API to convert documents, and I am noticing an initial delay of about 10 seconds before the conversion starts.

Why is this happening?


One of the likely reasons this could happen is if your PrizmDoc Server is not licensed properly or if you are running in the Evaluation mode. In such cases, there are restrictions in place.

Among those restrictions is an artificial delay of 10 seconds imposed before viewing or conversion operations begin. A dialog window normally indicates this in the Viewer interface, but if you are just making API calls to the server, it will not be apparent.

A valid product license is required to eliminate these restrictions, which can be done as follows:


Why is touch input for PrizmDoc Viewer not working in Chrome version 70+?


PrizmDoc Viewer uses the Chrome Touch API to process touch input. This API was deprecated after Chrome version 70, and must be manually re-enabled in order for touch input to work in PrizmDoc.

For Chrome versions 70-77:

Paste the following link into Chrome to enable the Touch API:


This issue will also occur in the Chromium version of Microsoft Edge.

Paste the following link into Edge to enable the Touch API:


For Chrome Versions 78+:

As of version 78 of Chrome, the touch-events flag has been removed from chrome://flags/ and edge://flags/.

To enable touch-events in versions of Chrome 78 and later, you must set a command-line flag at the end of the target path in your Chrome shortcut properties as demonstrated below:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --touch-events=enabled

We want to use one PAS instance for multiple customers while ensuring their calls and data are separated so that other customers cannot access them. Is there a way PrizmDoc can accomplish this?


How To:

Use the following steps to set up the multi-tenancy feature:

  1. Add a new line inside of /usr/share/prizm/pas/pcc.nix.yml (Linux) or C:\Prizm\pas\ (Windows) in the following format:

undocumentedFeature.multiTenancy: “enabled”

  1. After enabling this feature, all requests to PAS must include the header accusoft-tenant-id. The following shows an example request for creating a new viewing session:
POST /ViewingSession HTTP/1.1
Host: localhost:3000
Content-Type: application/json
accusoft-tenant-id: myUniqueTenantId
cache-control: no-cache
Postman-Token: 5edd698a-5e4f-46d2-b93a-42cc57371dce
  "source": {
  "type": "document",
  "fileName": "1040ez.pdf"

NOTE: All Tenant Ids are converted to lowercase and must be unique between tenants. This means that in terms of the application both “MyTenant” and “mytenant” are equivalent and would be able to see the same files. Tenant Ids are not generated for the application and must be generated and handled by the integration components. Tenant Ids are also strictly alphanumeric at this time.

File storage including Documents, markupXml, formDefinitions and markupLayerRecords will now be appended with the
{tenantId} as shown in the above example with a Documents configuration of /usr/share/prizm/Samples/Documents. The request would attempt to create a viewing session from the following file: /usr/share/prizm/Samples/Documents/myuniquetenantid/1040ez.pdf

Viewing Package data stored in the database will have the tenantId included in the composite index as well as include an accusoftTenantId column.