Technical FAQs for "PrizmDoc"

How can I remove the scroll bar/disable scrolling in PrizmDoc Viewer?

A quick way to do this would be to have something like the code below. Make sure to do this after this DOM element has loaded, so after the viewer is ready.

$('.pccPageListContainerWrapper').css('overflow', 'hidden');

The following will both remove the scroll bar, and disable scrolling:

$('.pccPageListContainerWrapper').css('overflow', 'unset');

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 would like to remove the mark selection handles from the marks (annotations and redactions) in the viewer so that my users can’t resize marks, but so they can still move the marks around. How can I do this?

The easiest way to achieve the functionality you’re looking for would be to simply change the CSS for the mark handles to set their display to none !important. The CSS for the mark handles can be found in viewercontrol.css. See the following code for an example:

/* mark selection handles */
.pccMarkHandleTopLeft,
.pccMarkHandleTopCenter,
.pccMarkHandleTopRight,
.pccMarkHandleMidLeft,
.pccMarkHandleMidRight,
.pccMarkHandleBottomLeft,
.pccMarkHandleBottomCenter,
.pccMarkHandleBottomRight,
.pccMarkHandlePoint,
.pccMarkHandleTextSelectionStart,
.pccMarkHandleTextSelectionEnd {
    position: absolute;
    width: 40px;
    height: 40px;
    display: none !important;
    background-image: url(data:image/png;base64,iVBORw...);
}

@media screen and (-webkit-min-device-pixel-ratio: 2), 
       screen and (min-resolution: 2dppx),
       screen and (min-resolution: 192dpi) {
    .pccMarkHandleTopLeft, 
    .pccMarkHandleTopCenter, 
    .pccMarkHandleTopRight, 
    .pccMarkHandleMidLeft, 
    .pccMarkHandleMidRight, 
    .pccMarkHandleBottomLeft, 
    .pccMarkHandleBottomCenter, 
    .pccMarkHandleBottomRight, 
    .pccMarkHandlePoint, 
    .pccMarkHandleTextSelectionStart, 
    .pccMarkHandleTextSelectionEnd {
        -webkit-background-size: 40px 40px;
                background-size: 40px;
        display: none !important;
        background-image: url(data:image/png;base64,iVBORw...);
    }
}

You will want to set the !important flag so that the functions inside viewercontrol don’t set the display back to block.

One thing you may want to do is separate out pccMarkHandleTextSelectionStart and pccMarkHandleTextSelectionEnd to not include display: none. This way, the text selection annotations are able to be edited, since they are reliant on the handles for "movement" because they select a portion of the text signified by the handles. 

What are the technical details/process of “Flattening” a PDF document?

It is possible to “Flatten” PDF documents in PrizmDoc Viewer. You can do this by converting the document to a raster format (TIFF is recommended for PDF conversion) using PrizmDoc’s Content Conversion Service, and then converting it back to PDF format. This will result in a PDF with a single layer and no hidden objects. However, this will usually lower the quality and increase the file size of PDFs that are largely text.

Here is an example workflow using the Workfile API and the Content Conversion Service API:

1. Create a WorkFile from PDF

POST {{pccisUrl}}/PCCIS/V1/WorkFile
Content-Type: application/octet-stream

{{file bytes}}

2. Initiate Conversion to TIFF

POST {{pccisUrl}}/v2/contentConverters
Content-Type: application/json

{
    "input": {
        "sources": [
            {
                "fileId": "{{fileId}}"
            }
        ],
        "dest": {
            "format": "tiff"
        }
    }
}

3. Poll until response[“state”] === “complete”

GET {{pccisUrl}}/v2/contentConverters/{{processId}}

4. Initiate Conversion from TIFF back to PDF

POST {{pccisUrl}}/v2/contentConverters
Content-Type: application/json

{
    "input": {
        "sources": [
            {
                "fileId": "{{fileId_from_Step3_output}}"
            }
        ],
        "dest": {
            "format": "pdf"
        }
    }
}

5. Poll again

GET {{pccisUrl}}/v2/contentConverters/{{processId}}

6. Download

GET {{pccisUrl}}/PCCIS/V1/WorkFile/{{fileId}}?ContentDispositionFileName={{desiredFileNameWithExtension}}

Why am I receiving a 500 error when making a Viewing Session PUT request?

This issue can occur if you forget to prefix the {viewingSessionId} portion of the URL with u, or if you simply request an invalid {viewingSessionId} in the call.

For example, the PUT call should look like the following:

PUT /ViewingSession/u{viewingSessionId}/SourceFile

For more information on syntax and other API calls related to Viewing sessions, please see:

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

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