Instead of the actual document text, Poppler renders this as a single page that
"To view the full contents of this document, you need a later version of the
PDF viewer. You can upgrade
to the latest version of Adobe Reader from
For further support, go to www.adobe.com/support/products/acrreader.html"
I think Poppler can do better.
Steps to reproduce:
1. Open http://undergradresearch.fsu.edu/Gfx/summer_award.pdf with Evince
Evince displays some lame error message embedded in the PDF.
Evince should display a "best effort" rendering of the actual text I want to
Does this happen every time?
This seemed similar to some other reported bugs in Evince, but in all the ones I looked at, highlighting the text made it visible. In this case, highlighting does nothing.
Not positive though.
Well, I originally filed this bug over at the GNOME Bugzilla, on Evince, but someone closed it "NOTGNOME" and said it was a Poppler bug. (The GNOME bug is #512160, but the database seems to be down at the moment...) Anyway, it has to be someone's fault! =)
BTW, is the example file technically a standards-compliant PDF, or a broken, non-standard one?
*** Bug 20490 has been marked as a duplicate of this bug. ***
*** Bug 35701 has been marked as a duplicate of this bug. ***
*** Bug 39592 has been marked as a duplicate of this bug. ***
*** Bug 39826 has been marked as a duplicate of this bug. ***
There is a 1500 page specification for XFA at
Needless to say, at this point I gave up.
I had post some feature request to okular but it probably for poppler :
There are some preliminary work in itext pdf here : http://support.itextpdf.com/node/134
It may help to implement basic support of xfa.
*** Bug 56913 has been marked as a duplicate of this bug. ***
Same as Mourad
with document: http://www.deutschepost.de/downloadServlet?target=/mlm.nf/dpag/images/e/einlieferungsliste/national_ip_20121211.pdf
on Gentoo Linux 64bit
Simply a polite question:
Will this issue be fixed in the near future or not?
XFA-Forms are becoming more and more important for me...
Thanks for answering :-)
Adobe would have to document XFA forms before this even could be addressed.
The most up to date info I could find on that front is:
As long as Adobe keeps XFA forms proprietary they are not potable and livecycle and acroread are the only way to deal with them.
Speaking only for myself, I’d go so far as to say that private, unpublished extensions to the PDF format make the file not PDF.
Support for ECMA-Script, on the other hand, is merely a matter of coding.
Until poppler or evince add it, you might want to try compiling mupdf master
(git clone git://git.ghostscript.com/mupdf.git)
with -DV8_PRESENT=1. You’ll need to install v8 first. Your distribution might pacakge it, else look at http://code.google.com/p/v8.
James, can you define the deficiencies in the spec linked from comment #9 so that we can understand which parts of XFA still need to be documented?
>>>>> "b" == bugzilla-daemon <firstname.lastname@example.org> writes:
> James, can you define the deficiencies in the spec linked from comment #9 so
> that we can understand which parts of XFA still need to be documented?
For starters www.xfa.org does not exist. And xfa.org does not have an A
or AAAA record.
It looks like the xfa situation isn’t as dire as I’d been led to understand.
OTOH, I’m not entirely certain that the licence text in the preface of the pdf referenced in comment #9 is GPL-compatible. Or even DFSG-compatible.
In any case (unless Albert things otherwise), it probably should not be implemented as part of poppler. I suspect an xfa-specific library would be better.
Poppler, of course, can help by assisting the extraction of the xml.
It is a huge (and likely non-Free) standard, will require web-browser-like implementation, and xfa is not limited to pdf encapsulation.
It might work better as an extension to webkit or gecko.
Most of the information I have about xfa has come from the itext list.
An example of the type of info posted there:
If there is new info since 2011/12 I’d be interested to know.
Sorry, but just to make sure, has there been any progress in the mean time?
The PDF viewer (pdf.js) included Firefox 45.3.0 is also *not* able to “correctly” display the form. There is an open issue in their bug tracker , where they take the stand, to not support it, until it’s part of the ISO PDF standard, and suggest to add support with an extension.
> Since this isn't currently part of the ISO standard there are no plans to
> implement it. Until it is in the ISO standard, it would probably be best if the
> support was added in some kind of "extension" to pdf.js in a separate repo.
> If someone is serious and wants put the work into adding it into mainstream
> pdf.js they should ping me and I could look into the implications.
1. Is XFA free?
2. What alternatives are there?
"Support XML Forms Architecture (XFA) forms"
Hi, I just wanted to note that this is an issue with some US gov't employment forms as well, particularly the I9 form. I filed the bug initially against GNOME / evince - see https://bugzilla.gnome.org/show_bug.cgi?id=785169