Technical FAQs

When printing in PrizmDoc, the bottom of my document is being cut off. Why is this happening?

When I download the document as PDF, I do not lose parts of the document. However, if I print the document to PDF, I lose some data off the very bottom (maybe an inch or so).

In PrizmDoc, the page is to "fit to width" onto the paper by design. The bottom of the page will be cut off in cases where the length of the page extends further than the length of the paper. If you’re printing with Letter size paper (the default), it presumes a document that measures 8.50 by 11.00 inches. Suppose your document measures 8.50 x 13.00 inches. That additional 2 inches will be cut off during printing. This is why you may lose parts of the document while printing, but not if you download the document since it’s downloading the document as-is.  

To prevent this from happening, select a paper size large enough for your document (in the viewer print dialog and the system print dialog). Using the previous 8.50 x 13.00 inch example, you can select "Legal" size paper, which measures 8.50 x 14.00 inches, and would be long enough to support that document.

You could also modify your viewer to add a custom paper size if this fits your use case. Below is some sample code demonstrating this in our Viewer sample. You would need to enter your own custom paper sizes.

https://www.accusoft.com/code-examples/printing-custom-paper-sizes/

Changes to printTemplate.html:

    /*custom */
    .portrait .custom.page { width: 11in; 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: 11in; 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*/

Changes to printOverlayTemplate.html (last line "Custom" is the only change):

    <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>

Additionally, if you would like to change the default selected page size you can add selected to it as follows:

<option value=\"a4\" selected><%= paperSizes.a4 %></option>

I have an evaluation license for PrizmDoc. Can I evaluate MSO features with this evaluation license?

No, regular PrizmDoc evaluation licenses do not have MSO functionality. They will instead use LibreOffice to convert documents. Contact an Accusoft Support Technician or your Account Representative to discuss evaluating PrizmDoc with MSO enabled.

ImageGear .NET v24.6 added support for viewing PDF documents with XFA content. I’m using v24.8, and upon trying to open an XFA PDF, I get a SEHException for some reason…

Why might this be happening?

One reason could be because you need to execute the following lines after initializing the PDF component, and prior to loading an XFA PDF:

// Allow opening of PDF documents that contain XFA form data.
IImGearFormat pdfFormat = ImGearFileFormats.Filters.Get(ImGearFormats.PDF);
pdfFormat.Parameters.GetByName("XFAAllowed").Value = true;

This will enable XFA PDFs to be opened by the ImageGear .NET toolkit.

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

We are saving files to the PDF/A standard and are running into a few cases where the file cannot be saved as PDF/A by ImageGear .NET. Why is this, and how do we do it properly?

First, determine whether a PDF document can be converted to PDF/A by creating an ImGearPDFPreflight object from your document, and generating an ImGearPDFPreflightReport object from it:

using (ImGearPDFPreflight preflight = new ImGearPDFPreflight((ImGearPDFDocument)igDocument))
{
    report = preflight.VerifyCompliance(ImGearPDFPreflightProfile.PDFA_1A_2005, 0, -1);
}

The first argument of the VerifyCompliance() method is the standard of PDF/A you want to use. ImageGear .NET is currently able to convert documents to adhere to the PDF/A-1A and PDF/A-1B standards:

PDF/A-1 Standard

ImageGear and PDF/A

There are parts of the PDF/A-2 and PDF/A-3 standards which may allow for more documents to be converted, but ImageGear .NET currently does not support those. This could possibly be why your document cannot be converted in ImageGear .NET.

Once the report is generated, you can access its Status, which will tell you if the document is fixable. You can also access its Code which will let you know if it’s a fixed page or if it has issues; it will return Success if fixed, or some error code otherwise. You can check these conditions to determine whether it’s worth attempting to convert the document:

// If the document is not already PDFA-1a compliant but can be converted
if ((report.Code == ImGearPDFPreflightReportCodes.SUCCESS) ||
(report.Status == ImGearPDFPreflightStatusCode.Fixable))
{
    ImGearPDFPreflightConvertOptions pdfaOptions = new ImGearPDFPreflightConvertOptions(ImGearPDFPreflightProfile.PDFA_1A_2005, 0, -1);
    ImGearPDFPreflight preflight = new ImGearPDFPreflight((ImGearPDFDocument)igDocument);
    preflight.Convert(pdfaOptions);
    saveFile(outputPath, igDocument);
}

// Create error message if document was not converted.
else if (report.Status != ImGearPDFPreflightStatusCode.Fixed)
{
    printAllRecordDescriptions(report);
    throw new ApplicationException("Given PDF document cannot be converted to PDFA-1a standard.");
}

If you want more information on why a document may not be convertible, you can access the preflight report for its records and codes. A preflight’s "Records" member is a recursive list of preflight reports. A preflight report will have a list of reports under Records, and each of those reports may have more reports, etc. You can recursively loop through them as seen below to output every reason a document is not convertible:

    private static void printAllRecordDescriptions(StreamWriter file, ImGearPDFPreflightReport report)
    {
        foreach (ImGearPDFPreflightReport rep in report.Records)
        {
            file.WriteLine(rep.Description);
            file.WriteLine(rep.Code.ToString() + "\r\n");
            printAllRecordDescriptions(file, rep);
        }
    }

Ultimately, the failure of a document to convert to PDF/A is non-deterministic. While some compliance failures can be corrected, in combination they may not be correctable. Therefore, the unfortunate answer is that to determine if it can be converted, conversion must be attempted.

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.