Sorry, I should have specified that part.

The original files are PDF and we're generating pages with minimal settings, but the files and the underlying images that are generated have no issues; it only seems to be the ImageHeight and ImageWidth properties for the first page.

The issue didn't start until after the updates and nothing has changed with the original files or the source process. I suspected Import Agent because we have pages being generated by things like Forms uploads and they haven't been affected.

To test, I ran some scripts that would read the page part image and found that even when the ImageHeight/ImageWidth properties were 0, the underlying image did in fact have a valid height and width.

After running some more tests I found that previously failed documents would suddenly be valid, so I kept removing testing steps to figure out what was "correcting" the problem.

Once I narrowed it down, I added an SDK Script that just reads PagePart.Image because after that is run and the script ends I no longer get 0 values.

For example, if I read the page part and immediately check the ImageHeight and ImageWidth, they will still show as 0 even if I draw a bitmap from the read stream and see non-zero values, but if I re-run the script it would be fine on the second attempt.

My best guess is that something is causing an issue with the first page's attributes on import/creation, but opening it in the client or reading the page part image is enough for it to self-correct.

Running the following as a separate activity before the image validation script somehow fixed the problem so I have that as a workaround step for now.

DocumentInfo doc = (DocumentInfo)this.BoundEntryInfo;

foreach(PageInfo page in doc.GetPageInfos()){
    if (page.HasImage) {
        if (page.ImageHeight <= 0 || page.ImageWidth <= 0) {
            using(LaserficheReadStream rs = page.ReadPagePart(PagePart.Image)){}
        }
    }
}

That's very different, thanks for the details. Import Agent has been updated to bring it up to date on PDF page generation fixes that we made for LF11. Does it happen for all PDFs? Does it happen if you generate pages through web/Windows client? Can you send some samples our way through your support people?

I was having a hard time identifying a sample because every document I copied seemed to work just fine when tested with a separate import profile.

However, I kept testing and discovered it is only affecting PDFs imported using XML, which is why the same files seemed to work in other attempts.

Attached is a sample PDF I created, and below is the XML I used to finally reproduce the issue, but with our server name edited out of the import path.

<?xml version='1.0' encoding='utf-8'?>
	<LF:importengine xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:schemaLocation='http://laserfiche.com/namespaces/importengine ImportEngine.xsd' xmlns:LF='http://laserfiche.com/namespaces/importengine' version='1.0'>
		<LF:toc on_document_conflict='unique' on_folder_conflict='unique'>
			<LF:document name='Test Document'>
				<LF:electronic_document content_type='application/pdf' extension='pdf' extract_text='false'>
					<LF:fileref ref='\\<servername>\D$\IA Test\TEST DOCUMENT.pdf' />
				</LF:electronic_document>
			</LF:document>
		</LF:toc>
	</LF:importengine>

I haven't tested with LST files, so it's possible they could be affected too.