Technical FAQs

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:

https://ideas.accusoft.com/ideas/PDV-I-655

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: https://help.accusoft.com/PrizmDoc/latest/HTML/prizmdoc-cloud-license-and-aws.html
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:
https://help.accusoft.com/PrizmDoc/latest/HTML/registry-changes.html?highlight=heap%2C.

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: https://help.accusoft.com/PrizmDoc/latest/HTML/prizmdoc-server-docker.html#2-configure-your-license.