[pdftex] Linux AR5.0.10 bug?: "Expected a name object" - Radio Buttons

[Marco Loskamp]

Dear Hans and Dear list,

I have finally solved my radio button problem, which I happily share so
others will hopefully not have to go through this ;-)

The new files are under (replace .tex by .log or .pdf to get those files)

  http://www.math.wisc.edu/~loskamp/FormBug-fixed.tex

Here's a more detailed description of the error:

On Thu, Jan 06, 2005 at 12:53:52PM +0100, Hans Hagen wrote:
> Marco Loskamp wrote:
> 
> >Would I need to insert additional entries like /NeedAppearances true or
> >others in the /AcroForm dictionary to make sure that the appearances are
> >generated?
> 
> indeed /Need... helps; although the initialization order of pdf is kind of 
> messy (different versions of acrobat have different order/priority in 
> doc/form/javascript initialization); i happily forgot the small details i 
> had to take care of -)

Yes, I have now a new version with /NeedAppearances true in the /AcroForm
dictionary, and the fields are visible right away. A significant improvement
to my earlier solution of generating an artificial /OpenAction JavaScript
that just "touched" all the fields by saying ``var f = this.getField("name");
f.value = f.value;''  which worked, but was a very unclean solution.

Back to the radio button problem:

I have finally found my problem with the original version: the /Fields[...]
entry in the /AcroForm dictionary should only contain references to parent
nodes, i.e. those that don't have ancestors in the field hierarchy (see PDF
Reference).
On the other hand, the /Annots[...] dictionary should only contain
annotations (and hence not the parent button field(s)).

Now, what happened with my file is that I declared a radio *parent* button 
as an annotation, so that ended up in the /Annots[...] array. BUT: a radio
button is NOT an annotation, it's only a simple PDF object. So, declaring
it with \pdfobj solved the problem. I'm soo thrilled it works now!

> >Even if the document doesn't contain any fonts?  It may very well be that
> >I technically produced "correct" PDF code, but that common applications
> >assume some "minimal amount of things in a PDF file," like fonts.
> 
> indeed, when viewing there are fallbacks that are not the same as when 
> printing (sometimes 'print as image' is a way out)

That is a neat hint which helped me in other situations. But it's actually
possible to have a font-free file.

> >Any additional input for the "Expected a name object" problem with Linux AR
> >5.0.10 will again be appreciated!
> 
> hm, for that i'd have to test in under linux first -)

So, now that I've solved the above problem, I still don't exactly understand
Linux AR's problem with a missing name object, but apparently, solving that
has now become redundant.


Thanks for your comments.
They have reduced the places to look at significantly!

Marco