[pdftex] Linux AR5.0.10 bug?: "Expected a name object" - Radio
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
> indeed /Need... helps; although the initialization order of pdf is kind of
> messy (different versions of acrobat have different order/priority in
> 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
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