Why am I unable to obtain a license using the License Manager?

One possibility is that you have strict firewall settings that are preventing our License Manager from connecting with licensing.accusoft.com, our licensing server. In order to connect with licensing.accusoft.com, you’ll have to make an exception in your firewall for our License Manager so that it can connect to licensing.accusoft.com on port 80 for http and port 443 for https.

I need to share a large file with Accusoft support. What should I do?

Accusoft FTP

EXISTING CUSTOMERS:

If you are an existing customer, you can access our server using any of the following with your current credentials:

To access the server with FTPS/SFTP using a browser, you may need to install/enable a plugin or extension. To access using HTTPS, you would use the URL shown above. FTPS and SFTP are accessible using most any FTP Client (e.g. filezilla, WinSCP etc.) Windows 10 b1803 and newer have sftp.exe built-in. This is a command-line-only utility for transferring files using SFTP.

Share with us from your Cloud Storage

You can share your files with us through your choice of service. Here are some of our suggested options below:

Google Drive

Dropbox

OneDrive

My document appears to be loading incorrectly. Are there any troubleshooting steps that I can take?

First, confirm that this is a document-specific issue by trying other documents of the same file type or documents of the same file type with similar size characteristics and content.

Second, if the document is a Microsoft Office document and you are using LibreOffice as your backend renderer, you can compare the way that the document displays in PrizmDoc against the way the document displays in the copy of LibreOffice shipped with PrizmDoc (C:\Prizm\libreoffice\program\soffice.exe on Windows, /usr/share/prizm/libreoffice/program/soffice on Linux). To inquire about the Microsoft Office renderer plugin, which may resolve office document rendering issues, send an email to sales@accusoft.com.

Third, reach out to a support technician at support@accusoft.com, as they will be able to quickly test how the document renders in the latest version of PrizmDoc, and consult the product engineers in the event that there is a rendering issue.

Have the following information handy, as it will help the support technician better assist you:

• What version of PrizmDoc are you using?

• What operating system are you using?

  • If Windows, are you using the LibreOffice or Microsoft Office backend renderer?

• A PDF export or a screenshot of what you see in PrizmDoc, compared to a screenshot of how the document looks in its native file type viewer.

• Log files that include the processing of the incorrectly loading document.

• Any changes that you may have made to the PrizmDoc configuration files.

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.

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.