Technical FAQs for "PrizmDoc Viewer"

Why are the fonts in my CAD files showing up garbled/unrecognizable/not as expected?

Some CAD files may include fonts that are not included in PrizmDoc Viewer’s default font set. PrizmDoc will choose the most appropriate substitute font to use in its place. The substitution process isn’t always perfect, and as a result, you will see garbled/unrecognizable characters in the Viewer.

In order to provide additional fonts for PrizmDoc to pull from,

Some CAD/DWG files may include fonts that are not included in PrizmDoc Viewer’s default font set. PrizmDoc will choose the most appropriate substitute font to use in its place. The substitution process isn’t always perfect, and as a result, you will see garbled/unrecognizable characters in the Viewer.

In order to provide additional .SHX fonts for PrizmDoc to pull from, you can copy the necessary .SHX font files into the cad-fonts folder, located at:

Windows: ‪C:\Prizm\modules\cad-fonts
Linux: /usr/share/prizm/modules/cad-fonts

Alternatively, if you want to use fonts from that are located in a different directory, you can add the environment variable, ACAD, to explicitly specify the filepath of these fonts. his variable can be added under System Properties > Advanced > Environment Variables > System Variables > New... > ACAD. For the variable’s Value, specify a folder path that contains additional CAD font files for PrizmDoc to pull from.

* It is important to note that the Linux filesystem is case-senstive, so when adding custom CAD fonts on Linux, make sure that the fonts are named with case-sensitivity in mind. If you still see unexpected output after adding the fonts to the cad-fonts folder, try renaming the fonts to all lowercase.

** Note that the cad-fonts folder was added in PrizmDoc 13.20, so to add custom cad fonts on earlier versions of Prizm, use the environmental variable approach.

you can add the environment variable, ACAD.
This variable can be added under System Properties > Advanced > Environment Variables > System Variables > New... > ACAD. For the variable’s Value, specify a folder path that contains additional CAD font files for PrizmDoc to pull from.

We are running PrizmDoc on a Windows operating system and we noticed that our ms-office-conversion-service remained unhealthy even through a restart of the service. We also noticed an error in the MsOfficeConverter.log referencing the following error. What could be the cause?

“WARN – COM error occurs on 1 initialization attempt. Retrieving the
COM class factory for component with CLSID
{000209FF-0000-0000-C000-000000000046} failed due to the following
error: 80080005 Server execution failed (Exception from HRESULT:
0x80080005 (CO_E_SERVER_EXEC_FAILURE))”

The PrizmDoc MSO feature requires either Microsoft Office 2013 or 2016 to be installed in order to function properly. Based on the error, there is a Microsoft Office specific .dll file which is not registered properly.

The following process will re-register the .dll files and potentially resolve this issue (Note: for Step 2, this may vary depending on what directory you used to install Microsoft Office and the version of Office. You want to find the directory containing winword.exe):

1. Run Command Prompt as Admin.
2. Type cd C:\Program Files\Microsoft Office\Office15 or cd C:\Program Files\Microsoft Office\root\Office16
3. Run winword.exe -regserver.
4. Reboot the server.

If you don’t have the Prizm service set up to run on boot then make sure that Office applications are started by PrizmDoc, or from the command line, before being opened manually.

I am trying to retrieve documents and files to view in PrizmDoc Viewer. The files are located in a NAS device. The file server is available via an HTTP link but I would prefer not to use the HTTP put method.

A NAS device is short for Network Attached Storage. Typically, to access these devices would be no different than a shared network drive from a server.

You can setup Prizm Application Services (PAS) to point to a NAS device, if there are actual file shares set up on that device. Also, a key note to remember is that both PrizmDoc and PAS should be running with a domain id which has full access to that share so that the services can access the files when called.

For instance, you have a folder on the NAS device called PrizmFolders and it is shared with a network drive share of \mynasdevice\PrizmFolders. You can modify the pcc.win.yml file to point to that root folder by updating the document.path as outlined below. Keep in mind that the backslashes have to be escaped so you will need an extra backslash for each backslash in the path:

documents.path:"\\\\mynasdevice\\PrizmFolders"

Once this is done, when posting a viewing session through PAS, you can simply specify the subfolder\filename. For instance, if there was a folder called northregion and a file called metrics.pdf (\mynasdevice\PrizmFolders\northregion\metrics.pdf) you would be able to specify northregeion\metrics.pdf in the post command.

Can we give network paths for source document location as well?

For example //10.216.2.312/test/test.doc

https://help.accusoft.com/PrizmDoc/latest/HTML/webframe.html#Transfer_Your_Document_to_PrizmDoc_Server.html.

When using http URL, for security reasons, only absolute paths are allowed, but could you map test to documents and use a local file?

Documents are stored by default in:

C:\ProgramData\Accusoft\Prizm\Documents 

so if the type in the request for source is document it will look in that folder. The configuration for that is set in PAS config:

    {
        "source": {
            "type": "document",
            "fileName": "1040ez.pdf"
        }
    }

No matter what CSS I use, the viewer’s div always consumes the full screen. How can I fix it?

If you’re trying to modify the PrizmDoc Viewer samples, then your CSS is most likely being overridden by the setting fullScreenOnInit: true. Change this property to false and you should be able to use any of the scaling CSS that you would use on a normal div.

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');

Is there a way to modify the colors used in PrizmDoc Viewer’s search results? In particular, the currently selected search result has a very similar color to the other results from the same term. Is there a way to increase the contrast?

Currently, we don’t support the ability to set anything other than the highlight color through the search API.

There is a feature request to enable such modifications:

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

I have already licensed PrizmDoc. Where can I find my license key?

At the very top of the prizm-services-config.yml file located at C:/Prizm/ on Windows and /usr/share/prizm/ on Linux, you can locate the license key:

######################### PrizmDoc Configuration ###############################

############################### Licensing ######################################

license.solutionName: ________
license.key: 2.0...

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.

In PrizmDoc, my document appears to be small on the page relative to the viewer. How can I fix this?

By default, PrizmDoc renders a PDF file according to the MediaBox, which is normally the same as CropBox, though sometimes this is not the case. The larger area you see in the PrizmDoc Viewer is the size of the MediaBox. Please note that the product provides the fileTypes.pdf.pageBoundaries control option (or useCropBox in the older versions) to change the default behavior. Try setting the option to cropBox in the Central Configuration File in order to get the PDF content rendered according to the CropBox. You can read more about configuring image frame rendering in our documentation here.

For additional reading, see 7.7.3.3 on “User Space” of Adobe’s PDF 1.7 specification:

https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf

Note: In some older versions of PrizmDoc, there exists an issue where setting the pageBoundaries field to cropBox can cause light blurring/distorting on the page. This issue was addressed in version 13.4.

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.