Technical FAQs

Which databases types are supported by PrizmDoc for storing annotation/redaction layers as well as viewing package information?

PrizmDoc provides the option to store viewing package process and creation information, as well as annotation layer JSON information, into a database.

Currently, Microsoft SQL Sever and MySQL is supported for this type of storage. For more information on setting up a database for use with PrizmDoc, please refer to the following documentation:

https://help.accusoft.com/PrizmDoc/latest/HTML/webframe.html#run-database-scripts.html.

https://help.accusoft.com/PrizmDoc/latest/HTML/webframe.html#developer-guide.html.

When deleting a Viewing Session, does the backend conversion stop?

No, the backend conversion will continue even after a Viewing Session is deleted.

I am creating a viewing session from a local document on my server and providing an absolute path “C:\Users\Public\Documents\Accusoft\Common\Images\PdfDemoSample.pdf” as the fileName but I receive a 404 error. What could be the reason for this and how can I fix it?

For security reasons, PAS disallows providing absolute paths for documents that are outside of the directory specified in the documents.path in the pcc.win.yml config file. So trying to provide a path to any file outside of that directory will cause a 404 error.

We recommend that you set documents.path to the directory in which you store your documents. When you create a create a viewing session using a local document, you should set fileName to the relative path to the document from the documents directory.

You can also set fileName to the absolute path to the document if it is contained in the documents directory (specified in pcc.win.yml) if you prefer to use absolute paths.

When viewing documents within the PrizmDoc Viewer using a particular browser, we are seeing garbage text. Viewing the same document with other browsers shows the text properly. What could be causing this to occur?

There are two possible causes for this in Internet Explorer 11 and you can check the settings below to potentially fix the issue:

In Internet Explorer 11 settings, ensure the Font Download option is enabled:

1. Click on Internet Options.
2. Select the Security Tab.
3. Under Local Intranet zone, select Custom Level.
4. Under Downloads, set Font download to Enabled.

Disable the “Turn off Data URI” support setting:

1. Click Start, type gpedit.msc in the Start Search box, and then press Enter.
2. In the navigation pane of the Local Group Policy Editor window, expand Computer Configuration > Administrative Templates > Windows Components > Internet Explorer > Security Features.
3. In the right pane, double-click Turn Off Data URI support.
4. Select Disable, click Apply, and then click OK.
5. Go back to the navigation pane of the Local Group Policy Editor window, expand User Configuration > Administrative Templates > Windows Components > Internet Explorer > Security Features.
6. Repeat steps 3 and step 4 above.

In Internet Explorer 11 settings, ensure Ignore font styles specified in webpages is not checked.

1. Click on Internet Options.
2. Select the General Tab.
3. Click on Accessibility button.
4. Un-check Ignore font styles specified in webpages.

In Chrome this is a bug that was found about 3 years ago and fixed in Chrome Canary, but not in Chrome Stable at the time:

https://productforums.google.com/forum/#!msg/chrome/rpmz56gnFKc/nPLtsbYZBwAJ

This may be why Chrome is having problems. Consider either updating Chrome Stable to the latest version or testing in Chrome Canary to see if that fixes the garbage character issues with that browser.

In Mozilla Firefox there is a setting you can enable which could resolve this problem in that browser:

1. Go to Options/Preferences > General: Fonts & Colors > Advanced and select Allow pages to choose their own fonts (instead of My selections above).

When trying to create a viewing session directory to the PrizmDoc back end over port 18681:

(POST http://prizmserver:18681/PCCIS/V1/ViewingSession)

why am I receiving a 500 internal server error?

There are some troubleshooting steps below you can take to verify the health of the server as well as ensure the API call you are making is properly formatted.

1. Verify the Prizm service is healthy by opening a browser on the Prizm server and using the following service health check URL (http://localhost:18681/admin)
2. Verify your POST command has all the required elements which can be verified in detail on the following documentation page:

https://help.accusoft.com/PrizmDoc/latest/HTML/webframe.html#viewing-sessions.html

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.

When viewing documents within the PrizmDoc Viewer using a particular browser, we are seeing garbage text. Viewing the same document with other browsers shows the text properly. What could be causing this to occur?

There are two possible causes for this in Internet Explorer 11 and you can check the settings below to potentially fix the issue:

In Internet Explorer 11 settings, ensure the Font Download option is enabled:

1. Click on Internet Options.
2. Select the Security Tab.
3. Under Local Intranet zone, select Custom Level.
4. Under Downloads, set Font download to Enabled.

Disable the “Turn off Data URI” support setting:

1. Click Start, type gpedit.msc in the Start Search box, and then press Enter.
2. In the navigation pane of the Local Group Policy Editor window, expand Computer Configuration > Administrative Templates > Windows Components > Internet Explorer > Security Features.
3. In the right pane, double-click Turn Off Data URI support.
4. Select Disable, click Apply, and then click OK.
5. Go back to the navigation pane of the Local Group Policy Editor window, expand User Configuration > Administrative Templates > Windows Components > Internet Explorer > Security Features.
6. Repeat steps 3 and step 4 above.

In Internet Explorer 11 settings, ensure Ignore font styles specified in webpages is not checked.

1. Click on Internet Options.
2. Select the General Tab.
3. Click on Accessibility button.
4. Un-check Ignore font styles specified in webpages.

In Chrome this is a bug that was found about 3 years ago and fixed in Chrome Canary, but not in Chrome Stable at the time:

https://productforums.google.com/forum/#!msg/chrome/rpmz56gnFKc/nPLtsbYZBwAJ

This may be why Chrome is having problems. Consider either updating Chrome Stable to the latest version or testing in Chrome Canary to see if that fixes the garbage character issues with that browser.

In Mozilla Firefox there is a setting you can enable which could resolve this problem in that browser:

1. Go to Options/Preferences > General: Fonts & Colors > Advanced and select Allow pages to choose their own fonts (instead of My selections above).

When viewing documents using Internet Explorer 11, we are noticing an abnormally high CPU utilization. It gets worse when zooming in up to 800% through the PrizmDoc Viewer. It only seems to happen on certain machines. Why might this be happening?

A possible factor for this type of performance issue can potentially be corrected by enabling Internet Explorer’s hardware acceleration feature.

This feature can be enabled or disabled with the following steps:

1. Open Internet Explorer 11, click on the Tools icon, and select Internet Options.
2. Navigate to the Advanced tab and enable the Use software rendering instead of GPU rendering option.
3. Click Apply and restart the browser.

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.

We are trying to create new viewing packages, however, in the [prizmdoc_process] table we see the process is 100% complete. However, the error code field indicates an Internal Error.

The document does not display in the viewing session and gives a 480 error. The following error code is:

{errorCode: “ViewingPackageNotUsable”}

What might be the issue?

When creating viewing packages, the PrizmDoc Application Services (PAS) uses the PrizmDoc Server to do the conversion work. In order for the viewing package to be created successfully, the PrizmDoc Server needs to be licensed and healthy.

If you see an error “ViewingPackageNotUsable” this can be related to the PrizmDoc Server either not being healthy or specifically not being licensed.

To verify the PrizmDoc Server status and if it is licensed, you can run the following command on the PrizmDoc Server in a web browser:

http://localhost:18681/admin