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

Marco Loskamp loskamp at math.wisc.edu
Tue Jan 11 08:24:09 CET 2005

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)


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
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!


More information about the pdftex mailing list