List & Label offers the possibility to use whole PDF documents within a report. In most cases, a letterhead or the terms and conditions already exist as a PDF document and can thus be easily added to a report.
But it also happens that scans - i.e. documents scanned via a scanner - are available as PDF documents and are to be used. However, a little caution is always required here. Even if the PDF document is only a few 100 KB in size (depending on the resolution, graphics are embedded in the PDF in a highly compressed form) and perhaps only consists of a single page, it is possible that the display in the List & Label report cannot be guaranteed, which has a technical background.
The PDF document is first converted into the Enhanced Metafile Format (EMF for short). In this process, graphics are converted into a bitmap, which, depending on the compressed graphics within the PDF document, can be very computationally and memory intensive. So the created EMF, of which the user of course is not aware, can quickly become several 100 MB in size and temporarily reserve several 100 MB in memory. This process can affect the display and use of the PDF object in the report. 32-bit applications in particular are quickly affected by this, since such a process can only use about 1 GB of RAM. And an application usually consists of more than just the reporting part with List & Label, so that the application itself must always be included in the memory consumption.
What measures can be taken to still be able to use the desired element in a List & Label report? There are the following three possibilities:
When creating PDF documents from scanners, compression can often be specified in advance. Often this can also be defined separately for graphics.
Due to the conversion of a PDF document into the EMF format when using high-resolution graphics, it may be better to use a graphic in the form of an picture object instead of the PDF document. Numerous formats are available for this purpose, such as PNG, JPEG, etc., which can often be created by scanner applications.
The application is converted from 32-bit to 64-bit. This does not solve the problem directly - but shifts it significantly further into the future, since in 64-bit applications significantly more memory can be addressed than in 32-bit applications and thus the conversion is enabled more reliably.