[poppler] Poppler 0.8.2 released

[Ross Moore]

Hi Albert,

On 04/05/2008, at 2:33 AM, Albert Astals Cid wrote:
> A Dissabte 03 Maig 2008, Ross Moore va escriure:
>> Hi Pino,

>> When AR opens the PDF it displays a message "Fixing Form Fields",
>> then opens the document anyway.
>> Until now, I've not known the reason for this.
>>
>> This also means that every PDF document containing form fields,
>> that has been created using pdfTeX with the hyperref.sty macro  
>> package,
>> has been technically invalid by having an empty  /Fields [ ]  array.
>>
>> Acrobat doesn't mind, since it fixes the document upon opening.
>> Other browsers need not do this --- with interesting consequences,
>> as we have discovered.
>
> Wait, we are not sure this is actually a real bug in the pdf, the  
> spec seems a
> bit not clear in that field,

Sure; and that's probably why the TeX macro coding is the way
that it is currently. Yet it can perhaps be improved.

My Maths Department has an automated quiz system that generates
1000s of such PDFs every semester for our students to use, and
has been doing so for many years now.
We recommend that they use AR to access and work with them,
because we know that other PDF browsers do not yet support
the form features properly --- at least that is what we have
assumed.  If that is actually false, and it is the documents
that have a defect, then there is great benefit in finding a fix.


Here is a quick analysis of what I think is going on.

The result of a simple 'grep' shows how the /Fields
key is inserted into the PDF using 3 different driver
mechanisms:

rossmoor% grep -C3 "Fields" *.def
hdvipdfm.def-  \@pdfm at mark{obj @corder []}%
hdvipdfm.def-  \@pdfm at mark{%
hdvipdfm.def-    obj @aform <<%
hdvipdfm.def:      /Fields @afields%
hdvipdfm.def-      /DR<<%
hdvipdfm.def-        /Font<<%
hdvipdfm.def-          /ZaDb @OBJZaDb%
--
hpdftex.def-\edef\OBJ at Helv{\the\pdflastobj}
hpdftex.def-\pdfobj{%
hpdftex.def-  <<%
hpdftex.def:    /Fields[]%
hpdftex.def-    /DR<<%
hpdftex.def-      /Font<<%
hpdftex.def-        /ZaDb \OBJ at ZaDb\space 0 R%
--
pdfmark.def-[%
pdfmark.def-  {aform}%
pdfmark.def-  <<%
pdfmark.def:    /Fields{afields}%
pdfmark.def-    /DR<<%
pdfmark.def-      /Font<<%
pdfmark.def-        /ZaDb{ZaDb}%


In the case of pdfTeX (using  hpdftex.def ) there is
currently no possibility of having a non-empty array; whereas
the  afields  identifier allows this in the other 2 cases.

But in those other cases, there is a separate program to be run
afterwards, once the TeX engine has completed its work.
This is when  afields  will be substituted by the list
of references to the top-level form-field nodes.

In the case of pdfTeX, these top-level nodes are not known,
for the current processing run, at the point that this coding
is encountered.


I plan to experiment with obtaining this information
from a previous processing run, assuming that the
PDF object reference numbers do not change
  --- after sufficiently many TeX processing runs.

At the same time, I can use the hierarchy of form fields
to remove a lot of redundancy in PDFs such as  5019-e-cmap.pdf
(e.g., the help-text of the popup images and their toggles).


> bit not clear in that field, do you know who wrote that piece of code?

The current maintainer of the  hyperref.sty  macro package
is Heiko Oberdiek. He is copied on this message.
However, that part of the coding is not necessarily his work;
it could well predate his involvement.



>
> Albert
>
>>
>>
>> Fixing this properly is going to require changes to the driver file
>>   hpdftex.def  (part of the  hyperref  macro package)  and probably
>> also changes within  pdfTeX  itself.

With any luck, it can be done in the macros only,
using information collected from the previous run.

A possible drawback is that PDFs from intermediate runs may
be broken in worse ways than what are currently produced.


>>
>>> I attached a very simple patch that checks whether the FormWidget*
>>> is valid,
>>> and the faulty pages of the documents seem to load fine now.
>>> Iñigo, what do you think?
>>
>> Thanks very much for this observation.
>> It gives me a good idea of both what was wrong, and also a way
>> to fix it --- for my owm documents, but not in full generality.
>>
>>> --
>>> Pino Toscano

>>
>> 	Ross


All the best,

	Ross

------------------------------------------------------------------------
Ross Moore                                       ross at maths.mq.edu.au
Mathematics Department                           office: E7A-419
Macquarie University                             tel: +61 (0)2 9850 8955
Sydney, Australia  2109                          fax: +61 (0)2 9850 8114
------------------------------------------------------------------------