Bug 14265 - Poppler doesn't render PDFs that check Adobe Reader is there using JavaScript
Poppler doesn't render PDFs that check Adobe Reader is there using JavaScript
Status: NEW
Product: poppler
Classification: Unclassified
Component: general
unspecified
x86 (IA32) Linux (All)
: medium major
Assigned To: poppler-bugs
http://undergradresearch.fsu.edu/Gfx/...
:
: 20490 35701 39592 39826 56913 (view as bug list)
Depends on: 14433
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-27 10:33 UTC by Keenan Pepper
Modified: 2014-03-05 23:07 UTC (History)
18 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Keenan Pepper 2008-01-27 10:33:25 UTC
Instead of the actual document text, Poppler renders this as a single page that
says:

"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
www.adobe.com/products/acrobat/readstep2.html
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

Actual results:
Evince displays some lame error message embedded in the PDF.

Expected results:
Evince should display a "best effort" rendering of the actual text I want to
read.

Does this happen every time?
Yes.

Other information:
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.
Comment 1 Brad Hards 2008-01-28 01:14:08 UTC
That appears to be implemented with javascript. I'm not sure if it is really poppler's job to do that. I'm seeing it more as part of the reader (e.g. okular or evince).

Not positive though.
Comment 2 Carlos Garcia Campos 2008-01-28 01:47:45 UTC
Well, javascript actions are not supported by poppler. The reader even doesn't know that there is javascript there if poppler doesn't support it. 
Comment 3 Keenan Pepper 2008-01-28 05:22:42 UTC
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?
Comment 4 Albert Astals Cid 2008-01-28 10:23:24 UTC
The pdf is ok, just doing ugly things to keep non acrobat readers viewers out of the game. And i think JavaScript handling should be done inside poppler, at least partially.
Comment 5 Albert Astals Cid 2011-06-19 15:18:18 UTC
*** Bug 20490 has been marked as a duplicate of this bug. ***
Comment 6 Albert Astals Cid 2011-06-21 12:15:13 UTC
*** Bug 35701 has been marked as a duplicate of this bug. ***
Comment 7 Albert Astals Cid 2011-07-27 04:44:24 UTC
*** Bug 39592 has been marked as a duplicate of this bug. ***
Comment 8 Albert Astals Cid 2011-08-04 05:22:33 UTC
*** Bug 39826 has been marked as a duplicate of this bug. ***
Comment 9 Adrian Johnson 2012-02-23 05:03:42 UTC
I started looking at what it would take to implement javascript. The problem is all the javascript in this pdf does is check the viewer version and if > 7.0 loads the "XFA" plugin. The pdf contains a stream with 600KB of XML starting with "<template xmlns="http://www.xfa.org/schema/xfa-template/2.1/">".

There is a 1500 page specification for XFA at
http://partners.adobe.com/public/developer/en/xml/xfa_spec_3_3.pdf

Needless to say, at this point I gave up.
Comment 10 newbeewan 2012-05-14 00:33:06 UTC
Hi,

I had post some feature request to okular but it probably for poppler :
https://bugs.kde.org/show_bug.cgi?id=299816

There are some preliminary work in itext pdf here : http://support.itextpdf.com/node/134

It may help to implement basic support of xfa.

Best Regards

Mourad
Comment 11 Albert Astals Cid 2012-11-09 18:33:35 UTC
*** Bug 56913 has been marked as a duplicate of this bug. ***
Comment 13 spam-mails-here 2013-06-26 11:37:03 UTC
Hi,

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 :-)
Comment 14 James Cloos 2013-06-26 21:27:09 UTC
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:

    http://en.wikipedia.org/wiki/XFA#Standardization

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.
Comment 15 Bill McGonigle 2013-07-10 15:23:45 UTC
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?
Comment 16 James Cloos 2013-07-10 21:48:09 UTC
>>>>> "b" == bugzilla-daemon  <bugzilla-daemon@freedesktop.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.

-JimC
Comment 17 James Cloos 2013-07-10 23:30:42 UTC
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.
Comment 18 James Cloos 2013-07-11 00:11:04 UTC
Most of the information I have about xfa has come from the itext list.

An example of the type of info posted there:

http://support.itextpdf.com/node/134

If there is new info since 2011/12 I’d be interested to know.