Bug 693446 - MuPDF can't render PDF document which contains XFA forms
Summary: MuPDF can't render PDF document which contains XFA forms
Status: NOTIFIED WONTFIX
Alias: None
Product: MuPDF
Classification: Unclassified
Component: fitz (show other bugs)
Version: unspecified
Hardware: All All
: P4 enhancement
Assignee: Tor Andersson
URL:
Keywords:
: 696108 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-11-13 19:50 UTC by Mike Gorchak
Modified: 2018-11-15 13:50 UTC (History)
4 users (show)

See Also:
Customer: 580
Word Size: ---


Attachments
This document can't be rendered (325.94 KB, application/pdf)
2012-11-13 19:50 UTC, Mike Gorchak
Details
This document is rendered fine. (617.65 KB, application/pdf)
2012-11-13 19:51 UTC, Mike Gorchak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Gorchak 2012-11-13 19:50:21 UTC
Created attachment 9080 [details]
This document can't be rendered

I've two similar (similar from my point of view) PDF documents. One of them, IMM5257B_1.PDF, which contains fillable forms is rendered fine in r/o mode. While second document, IMM1295E.PDF, is not rendered properly. MuPDF engine renders only one page which contains:

"To view the full content of this document, you need a later version of the PDF viewer. You can upgrade to the latest version of Adobe Reader from ...."
Comment 1 Mike Gorchak 2012-11-13 19:51:02 UTC
Created attachment 9081 [details]
This document is rendered fine.
Comment 2 zeniko 2012-11-13 20:25:02 UTC
This is because MuPDF doesn't support XFA forms (which per http://code.google.com/p/sumatrapdf/issues/detail?id=1294 seem to be used by various governments and other public institutions).
Comment 3 Max 2014-10-07 03:03:11 UTC
Some references with regards to xfa can be found in  http://blog.idrsolutions.com/2013/09/xfa-articles-index-understanding-xfa/ although it should be taken with a grain of salt: their own soft suck tremendously at handling xfa :)
Comment 4 Ray Johnston 2015-05-21 16:27:21 UTC
This still is shown as P4 enhancement even though the customer field has been
set.

IMHO, this is a long shot, but definitely more likely to be done with mupdf
than ever with GS (ref bug 695117) since mupdf at least can support some
form filling (AFAIK).

Note that if we do this, it will probably be the first since I can't find
any open source for XFA form filling (Adobe has dropped linux support for
Acrobat that had XFA)
Comment 5 Ken Sharp 2015-05-22 00:25:46 UTC
(In reply to Ray Johnston from comment #4)

> Note that if we do this, it will probably be the first since I can't find
> any open source for XFA form filling (Adobe has dropped linux support for
> Acrobat that had XFA)

I believe iText can handle XFA forms.
Comment 6 Robin Watts 2015-09-25 10:35:40 UTC
*** Bug 696108 has been marked as a duplicate of this bug. ***
Comment 7 Tor Andersson 2015-11-04 01:19:26 UTC
The first document uses dynamic XFA: it's a thin PDF wrapper around an XFA document which describes the entire page content, including text and images that are not part of the form.

The second document uses static XFA: the XFA form is defined to sit on top of existing AcroForms. This kind of document we already handle well enough to display, since the vital form information is duplicated between XFA and AcroForm.

In order to support the first document, we need to add a completely new document format handler to MuPDF to sit along side PDF, XPS and EPUB: XFA.
Comment 8 Tor Andersson 2018-11-15 13:50:46 UTC
XFA forms are deprecated in PDF 2.0.