Complex XFA forms fail to render properly (or at all), with XFA enabled.
See original GitHub issueAttach (recommended) or Link to PDF file here:
Market Authorisation Application form from the European Medicines Agency.
The screenshots and attached file is a “variation form” that is a bit smaller (and easier to fill out).
Filled out version of the variation form.
Configuration:
- Web browser and its version:
Google Chrome | 91.0.4472.77 (Officiell version) (64 bitar) (cohort: Stable)
Version | 1cecd5c8a856bc2a5adda436e7b84d8d21b339b6-refs/branch-heads/4472@{#1246}
- Operating system and its version: Windows 10 (1909)
- PDF.js version: Online demo version + tested with a local build from master today.
Steps to reproduce the problem:
- enableXfa = true
- load the PDF
What is the expected behavior? (add screenshot)
The expected behavior is what Adobe Reader renders, or at least something similar. I am aware that XFA support is still experimental, at best.
What went wrong? (add screenshot)
Some parts render OK, but the more complex parts look really strange.
There are also lots of warnings like this in the console:
Warning: XFA - Invalid reference: $record.envelope.lists.eeaCountriesExcludingUkNi.item[*].
Warning: XFA - Invalid reference: $record.envelope.lists.eeaCountries.item[*].
Warning: XFA - Invalid reference: $record.envelope.lists.countries.item[*].
Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension): N/A
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (1 by maintainers)
Top GitHub Comments
@sictransit let’s keep this open to track rendering this form as it is supposed to be rendered (it is a pretty complex one!)
The latest pre-release (https://github.com/mozilla/pdf.js/releases/tag/v2.11.338) certainly does a much better job. All the information is there, except for scanned signatures.
Issues I’ve noticed: