[poppler] Changed renderings due to Annot/Form changes

Carlos Garcia Campos carlosgc at gnome.org
Sun Mar 27 09:28:44 PDT 2011


Excerpts from Carlos Garcia Campos's message of dom mar 27 12:44:56 +0200 2011:
> Excerpts from carlosgc's message of jue mar 24 11:30:54 +0100 2011:
> > Excerpts from Albert Astals Cid's message of vie mar 11 09:31:51 +0100 2011:
> > > Hi Carlos, the following files suffer from rendering changes due to Annot/Form 
> > > changes, sometimes is just that the "tick" mark moved up a bit, and sometimes 
> > > a "radio button" drawing got replaced by a "cross".
> > > 
> > > As far as I understood you said there should be no rendering difference at all 
> > > so i'm sending the whole list so that you can have a look and fix the 
> > > regressions.
> > > 
> > >  * https://bugs.kde.org/attachment.cgi?id=26497
> > 
> > If the problem here is the check buttons, it's not a regression, but a
> > feature :-) we are now correctly using the appearance stream of the
> > annotation. 
> > 
> > >  * Document not in the internet (will mail to you)
> > >  * http://launchpadlibrarian.net/11456651/f1040nre-2007.pdf
> > 
> > Ditto.
> > 
> > >  * Document not in the internet (will mail to you)
> > >  * http://launchpadlibrarian.net/14733056/Absentee%20Ballot.pdf
> > 
> > Ditto.
> > 
> > >  * https://bugs.freedesktop.org/attachment.cgi?id=29612
> > 
> > Can I see the differences? or did you remove the results already?
> 
> Ok, this one is also better now. 
> 
> > >  * http://www.tcpdf.org/examples/example_054.pdf
> > 
> > This doesn't look correct compared to acroread, I'll look at it in
> > detail.
> 
> I've just fixed it in git master, I was ignoring the NeedAppearances
> entry in AcroForm dict for some cases. It fixes the regression and
> improves the output, but it still doesn't look like acroread. 

I think the document is buggy, I'm not sure why it works in acroread
though, see:

13 0 obj
<< /Type /Annot /Subtype /Widget /Rect [0 0 0 0] /T (radioquestion)
/FT /Btn /Ff 49152 /Kids [ 15 0 R 15 0 R 16 0 R ] /V /2 >>
endobj

And we render both annots correctly, but there's a field
referenced in the Annots array but not in AcroForms nor kids array of
any form field:

14 0 obj
<</Type /Annot /Subtype /Widget /Rect [42.52 633.35 55.02 645.85] /FT
/Btn /Contents (þÿ^@r^@a^@d^@i^@o^@q^@u^@e^@s^@t^@i^@o^@n) /P 26 0 R
/NM (0001-0002) /M (D:20110323184058+01'00') /F 4 /AS /Off /AP << /N
<< /1 35 0 R /Off 36 0 R >> >> /BS << /Type /Border /W 1 /S /I >> /MK
>> << /BC [ 0.50 0.50 0.50] /BG [ 1.00 1.00 1.00] /CA (l) /IF << /A
>> [0.50 0.50]>> /TP 0>> /Parent 13 0 R /Ff 49152 /DA (/F3 10.00 Tf
>> 0.000 0.000 0.000 rg)>>
endobj

Since it doesn't have a field associated we simply draw the AP, that's
the first radio button you can see it's rendered wrongly. I think the
document is wrong and the first object should contain 14, 15 and 16 as
kids instead of 15, 15, 16.

I've also noticed that there are other documents failing now, because
they have a radio button field whose children are composed field +
annot dicts containing a DA. In that case we fail to generate the
appearance stream because we can't find the DA in the radio button
field, we are assuming the children of a radio button field is an
annotation, and we ignore any other entries in the dictionary. For
example:

5 0 obj
<</FT/Btn
/P 1 0 R
/Kids[6 0 R 8 0 R 9 0 R ]
/T(OptionButton)
/TU<FEFF>
/Ff 32768
/V /1
/DV /1
>>
endobj

This is the radio button, it doesn't have a DA, but look at one of the
children:

6 0 obj
<</Type/Annot/Subtype/Widget/F 4
/Rect[237.7 765.7 248 775.6]
/FT/Btn
/P 1 0 R
/Parent 5 0 R
/TU<FEFF>
/DR<</Font<</ZaDb 18 0 R/HelvReg 17 0 R>>>>
/DA(0 0 0 rg /ZaDb 0 Tf)
/MK<</CA(l)>>
/AP<<
/N<< /1 22 0 R /Off 23 0 R>>
>>
/AS /1
>>
endobj

It's a composed dict (field + annot) but we are assuming that form
fields having children that look like annotation dicts are terminal
fields, so we create a widget from this annot, but we ignore all other
entries, like DA in this case. Without the DA we fail to create an
appearance stream for the widget annotation.

I'm working on this already, but I'm afraid it will take some time,
since I have to re-think the way we build the fields tree. We are also
ignoring container fields (non-terminal fields that have non-terminal
children). 

> > >  * http://librarian.launchpad.net/1607136/evince.pdf
> > 
> > Ditto. (not a bug)
> > 
> > >  * Document not in the internet (will mail to you)
> > 
> > You have sent 3 documents to me, one twice (I guess by mistake) that
> > seems to be the same document than example_054.pdf, and the other one
> > looks correct. 
> > 
> > > Albert
> > 
> > Thank you very much for running the test suite, I'll look at the
> > two documents that are incorrectly rendered in detail.
> > 
> > Regards, 
> 
> Regards,

Regards, 
-- 
Carlos Garcia Campos
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20110327/c0657cd6/attachment.pgp>


More information about the poppler mailing list