The following items are either currently under investigation by the Accusoft Engineering organization or provide further information regarding PrizmDoc. Should you require an updated status on any of these items, please contact Accusoft Customer Support.
Note: For complete PrizmDoc documentation, refer to the PrizmDoc Online Help.
Currently, the path PrizmDoc is installed to on Windows cannot exceed 64 characters total. Longer paths are rejected by the installer.
When installing PrizmDoc on Windows, the account used to start the Prizm service requires a password to be defined. Without a password, the Installer will not be able to proceed.
Note that we have modified the default properties for several marks when creating them via the API. As long as you are setting mark properties, such as color and line width, this should not affect your code.
E-Signing is not currently supported on Internet Explorer 8. It is generally not possible to get usable font alignment when working on-screen or when burning documents.
There are known issues with E-Signing when working on iOS devices that can cause the screen to move erratically when moving from field to field. This does not keep the experience from being usable, but it can be disconcerting while using.
There are limitations to using the Full-Page Redactions mouse tool on a mobile device.
When requesting raster page content, a '500' error may appear in the network log. As part of performance improvements, the viewer now always requests SVG content first. If SVG content is not available, a '500' error will be communicated and the client will then request raster content. Although this does not negatively affect the viewer behavior, this will be changed in a future release to handle the request differently.
The Content Encryption feature is not supported in IE8.
When printing a document in Firefox or Safari, embedded images may be truncated or missing in some cases.
When printing a document in Chrome, images may be printed with a black background when the background should be transparent.
IE8 Documents are now searchable in PrizmDoc. However, there are cases where the initial search on a cold cache may fail but subsequent searches are successful.
PDF files with embedded raster images in the Indexed color space using CMYK palette might not display with the correct colors in the Viewing Client after conversion to SVG.
Search results returned in the Viewing Client for PDF documents may not be highlighted in cases where the PDF contains image over text results. In this case, content will be returned in the Search results tab, but the highlighted search terms will not be displayed in the page view when navigating to the appropriate page. In this case, a message will be displayed indicating that the page does not support text highlighting. This will be improved in future versions.
It is recommended that the document cache be cleared prior to upgrading PrizmDoc. Failure to clear the cache will result in the inability to search documents in the Viewing Client that have been cached in prior versions of PrizmDoc.
In some cases, very large documents (>500 pages) may not return all search result pages for a document. In this case, the warning icon will be displayed indicating that there are pages that could not be searched. In isolated cases, search results may be returned in the results pane but do not display a corresponding highlight in the page view. This can occur when there is a discrepancy between the extracted text and the SVG rendering of that text.
When printing documents with the Viewing Client in Safari browser on Windows, blank pages are sometimes created, causing extra pages in the document.
Known Issues for Text Annotations when Using IE9 in Standards/Native Mode:
After the text is entered to the edit box in the annotation object, the annotation object is still in the selected/edit mode and currently the lines will appear to be wrapping far too soon. It appears that only a 1/4 width of the rectangle is occupied. When a single-click is made, (outside the Text annotation object so that the annotation object is not in edit mode anymore), then at this point the lines will wrap at around 3/4 width of the bounding rectangle.
For certain bounding rectangle widths, (when resizing the width), the lines wrap just after single words.
If a word width is longer than the width of the bounding rectangle, then the word will bleed across the right edge of the rectangle. Wrapping within a single word with a dash is not implemented.
PrizmDoc Server v11.2 is using ImageMagick which is open to the following security vulnerabilities:
While the Windows distribution of PrizmDoc Server does include ImageMagick along with the patch, Linux distribution of PrizmDoc Server does not include ImageMagick. When installing ImageMagick on Linux Server, please make sure to address the listed security vulnerabilities by modifying the ImageMagick policy.xml file (with default location: /etc/ImageMagick/policy.xml) to make sure it contains the following policy mappings:
<policymap>
<policy domain="coder" rights="none" pattern="EPHEMERAL" />
<policy domain="coder" rights="none" pattern="HTTPS" />
<policy domain="coder" rights="none" pattern="HTTP" />
<policy domain="coder" rights="none" pattern="URL" />
<policy domain="coder" rights="none" pattern="FTP" />
<policy domain="coder" rights="none" pattern="MVG" />
<policy domain="coder" rights="none" pattern="MSL" />
<policy domain="coder" rights="none" pattern="TEXT" />
<policy domain="coder" rights="none" pattern="LABEL" />
<policy domain="coder" rights="none" pattern="SHOW" />
<policy domain="coder" rights="none" pattern="WIN" />
<policy domain="coder" rights="none" pattern="PLT" />
<policy domain="path" rights="none" pattern="@*" />
</policymap>
The following TTC font packages on Ubuntu might conflict with Tunga and Latha font substitution implemented in PrizmDoc Office Converter causing inaccurate rendering. You may need to uninstall those packages for better font substitution fidelity:
You may see space between the image tiles (when rendering raster images that are broken into tiles, within HTML tables) if those tables do not fit into one page.
When using PrizmDoc Server in a self-hosted Docker environment, international symbols may not be redacted correctly. In order for international symbols to be redacted correctly, make sure a unicode locale, for example, en_US.UTF-8, is enabled. Add the following settings to your Docker configuration file:
# generate and enable en_US.UTF-8 locale
RUN locale-gen en_US.UTF-8
ENV LANG en_US.UTF-8
ENV LANGUAGE en_US:en
ENV LC_ALL en_US.UTF-8
The new Email Conversion Service fidelity improvements will result in shifting the rendered content (due to inline image rendering support for more accurate rendering of the HTML body) and making the existing annotation and redaction markup not aligned with the old rendered content. Customers wanting to redact the new output would need to re-create the annotation and redaction markups.
Excel worksheets will now be rendered with grid lines, headers, footers, and hidden content visible by default causing the existing annotation and redaction markup to be not aligned with the old rendering content. Customers wanting to redact the new output would need to re-create annotation and redaction markups. Customers wanting to go back to the old style rendering can do that by changing the Excel rendering properties available in the central configuration file.
Embedded OLE objects in CAD files are not currently supported for rendering.
Conversion failures observed for simultaneous EML and MSG files conversions on Windows 2012 R2 multi-processor configurations.
Ubuntu 14.04 kernel v3.13.0-48-generic has been shown to be unstable, which has led to crashes in the version of Mono used by PrizmDoc (https://bugzilla.xamarin.com/show_bug.cgi?id=29212). Upgraded kernel v3.13.0-70 has been validated for use with PrizmDoc on Ubuntu 14.04, and its use is strongly recommended.
Deep Image Redaction may not work as expected when the source PDF contains G32D encoded TIFF images. PDF redactions will be created but any content on the G32D encoded content intended for redaction will not be obscured by black pixel data.
There are some special symbols, such as '@', that cannot be properly processed in auto-redaction.
When converting HTML to PDF using the Content Conversion Service, you may see see poor performance on larger documents when pdfOptions.forceOneFilePerPage is set to true. We recommend that pdfOptions.forceOneFilePerPage be set to false when converting more than 20 pages.
Watermarking is not supported for CAD files.
The MarkupBurner, responsible for the underlying process of redaction and esignature, does not currently support CAD based files.
The ext3 file system limits the number of subdirectories within a single directory to 31,998. Because PrizmDoc creates a directory for each viewing session and/or work file, systems with high traffic combined with longer cache expiration periods may encounter request errors with ERROR_GEN_FAILURE. The ext3 file system is the default for ephemeral drives in AWS as well as many current Linux distributions. Consequently, the possibility of encountering this error exists for these systems unless ext4 was specifically chosen at installation. To enable directories containing greater than the 32K subdirectory limit, ext4 turns on HTree indexes (a specialized version of a B-tree) by default. For systems with extraordinarily high traffic coupled with extended cache expiration times, it is recommended the product be installed on Linux systems with ext4 file systems or at least to configure caching to utilize an ext4 file system.
The PrizmDoc RESTful API is no longer supported on CentOS 5.8.
Watermarks appear in bold and are not transparent.
The PrizmDoc Server "GET Page" call requesting a JPEG thumbnail for a certain page hosted on Windows might return HTTP error 500.
When the conversion of the source file reaches the timeout in the PrizmDoc Server, the text search interface may not return all results from all pages. Note that the default conversion timeout is 10 minutes and can be extended by setting the values of http_response_timeout and worker_timeout in proxyserver_jar.properties.
The "extractattachments" REST API command creates a directory of the email attachments along with the additional temporary directories in the same location where the target is specified. The temporary directories contain body.rtf and body.txt and they remain after the "extractattachments" command is finished.
Write access to the Prizm\bin folder is required for working with e-mail message attachments.
Excel pagination is not currently supported for CSV files, causing incorrect page count.
Excel pagination causes the Office converter to generate more pages. This puts more stress on the server and may cause the conversion to timeout.
PrizmDoc running on Linux requires an X11 server to perform conversions for the HTML5 Viewer:
In order to convert some documents into PNG format used by the HTML5 Viewer, PrizmDoc on Linux requires an X11 server. If you have installed the product on a headless Linux server you will need to, at a minimum, run the X virtual framebuffer server to facilitate the conversions:
Install the X virtual framebuffer server.
Debian/Ubuntu:
# sudo apt-get install xvfb
Red Hat/CentOS:
# yum install xorg-x11-server-Xvfb
Start the X virtual framebuffer server. This must up and running any time the Prizm service is started.
# Xvfb :20 >/dev/null 2>&1 &
Export a DISPLAY environment variable for the Prizm Service to know where the X11 server is.
# export DISPLAY=:20
Start the proxyserver.
# /usr/share/prizm/scripts/proxyserver.sh start
Conversion of EMF and WMF files (to Raster or SWF files) produces files with a transparent background color instead of the expected solid background color.
Certain VML shapes from Word documents might not render properly to the client viewers.
If you have been providing a value for input.sources[n].pages when converting to a destination of PDF, that value will no longer be ignored (as it was in v10.3), but will now control which pages in the input files are included in the final PDF.
Legacy PDF Watermarks: Text Watermarks show bold (not transparent) in the output PDF when added to PDF or Office documents.
CAD conversion to SVG: Vector Conversion Service adds geometry from the source CAD file to the output SVG. Since SVG is an XML-based vector image format for two-dimensional graphics, it does not support certain geometry like light sources, materials, etc. As a result, CAD chart with such elements will look like a "wired" model converted to SVG. In order to represent a CAD chart as a "solid" model, the Viewing Client should be configured for raster rendering. However, Vector Conversion Service uses OpenGL rendering for rasterizing CAD geometry, and the current support of OpenGL rendering within PrizmDoc is limited to Windows only.