[poppler] Patches for form choice fields

[Leonard Rosenthol]

I haven't looked at the file or the issue, but since you mentioned encoding, I can point out that the handling of values for encodings can indeed vary and based on the field types.  The details are all as specified in 32K-1:2008, but you may need to read carefully.

Leonard

-----Original Message-----
From: poppler-bounces+leonardr=adobe.com at lists.freedesktop.org [mailto:poppler-bounces+leonardr=adobe.com at lists.freedesktop.org] On Behalf Of Fabio D'Urso
Sent: Sunday, October 14, 2012 10:26 AM
To: poppler at lists.freedesktop.org; Carlos Garcia Campos
Subject: Re: [poppler] Patches for form choice fields

On Sunday, October 14, 2012 11:17:19 AM Carlos Garcia Campos wrote:
> Excerpts from Fabio D'Urso's message of dom oct 14 03:21:18 +0200 2012:
Hi Carlos,

> > 0002
> > [...]
> > This patch adds support to write the /I field, which is the list of 
> > the indices of the selected items. According to PDF specs, it is 
> > mandatory only under some circumstances, but tests showed that 
> > acroread always require it.
> 
> Even for non multiselect form choice fields? The spec says "This entry 
> should not be used for choice fields that do not allow multiple 
> selection", so I think we should not write the I entry when 
> isMultiSelect is false.

I had tested it, but acroread then failed to recognize the currently selected
item: it correctly shows the value (eg "Green") but doesn't highlight it in the dropdown box. In other words, I guess that acroread thinks that "Green" is a value typed by the user.
I'm attaching test1.diff for you to test yourself.

At first I tought that it was that same encoding issue we have (ie we write
UTF16 but acroread expects PdfDocEncoding), so I had also tested test2.diff, which didn't work either.

Now, I've just made a new test (test3.diff), that writes the export value instead of the option name. This is the same incorrect behavior (*) as foxit but, suprisingly, it works.
* = See the last paragraph in 12.7.4.4 "Choice fields"

To sum up, yesterday it seemed to me that acroread always expects /I, even when the specs say it shouldn't. Actually acroread doesn't, but it incorrectly expects /V to contain the "export value" instead of the "option name", and that's why my tests showed that /V was ignored.
If /I is present, acroread gives it precedence over /V [test4.diff] (once again, against the specs, see last line in table 231).
Quite confusing... :D

So we have two working options:
 - Always write /I, not matter if multiselect is true or false (current
   approach in my 0002 patch)
 - Only write /I if multiselect is true, but write export values instead of
   option names in /V, which is also against the specs [alternative0002.patch]

> 
> [...]

> > 0004
> 
> I think we should fix this anyway for documents containing single 
> selection choice fields, or previously saved by poppler.

Sure we can, especially if we decide not to write /I if !multiselect.
On the other hand, I'd not consider old poppler-saved documents a priority because those documents never worked properly: neither acroread nor poppler itself could read them back correctly.

> > I could have changed this piece of code to make it aware of 
> > different encodings but it seemed to me that reading /I is a more 
> > robust option for two
> > 
> > reasons:
> >  - it better deals with duplicate items (ie items with the same 
> > value)
> >  - foxit reader stores the wrong value in /V: it writes what we call
> >  
> >    "exportVal" instead of what we expect ("optionName"). The /I field is
> >    always correct instead.
> 
> I guess we shouldn't decide our code based on foxit bugs.

I agree in general, in this specific case this "workaround" came at no cost.
Now, given the results of test3.diff and alternative0002.patch, I begin to doubt it was a foxit bug at all...

Fabio