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: [email protected] [mailto:[email protected]] On Behalf Of Fabio D'Urso Sent: Sunday, October 14, 2012 10:26 AM To: [email protected]; 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 _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
