attachment 106922 [details] is a PDF form I created with the latest pdflatex (attachment 106923 [details] is its sourcecode). It fulfils the PDF form specification. In Okular 1.11 (Windows nightly build 585) the bug is: - open the PDF and go to sec. 2.4 - There click on the third button of the section result: nothing happens expected result: a website should be opened. This works correctly with Adobe Reader.
> It fulfils the PDF form specification. Sure, it fulfills the PDF specification, but it's also kind of malformed, it has two two link actions in the very same place, one of the link actions has an empty JS associated to it and the other link action has a url associated to it. So we decide that left click goes to one and you like the other, you can access the other with right click. Honestly i'm not sure why we would prioritize one over the other, i guess we could do some pretending to be smart like "if there's two actions on the same place and one has a http url and the other an empty JS, ignore the one with the empty JS", but idk, feels dirty
Is that something that we could ask Leonard about?
Sure, ask away
Here is his answer: "The order of the Annotations in the Annots array in the page dictionary defines the order in which rendering and hit testing is performed. However, there is nothing that precludes you doing what you're doing with the multiple click choices as well." So I suppose what should be done is process all actions in order. The first one will not require special filtering, because executing an empty JS program is a no-op.
> So I suppose what should be done is process all actions in order. The first one will not require special filtering, because executing an empty JS program is a no-op. I don't think that is what Leonard means, or at lest not what i understand, "hit testing" means the one first wins, not all in the same location are executed.
I asked Leonard for clarification, and here is his answer: > To avoid misunderstanding: Do you mean that a reader should process *all* actions (in the order you describe), or just the first one? We should be careful about the terminology here. The PDF that I saw had multiple *annotations* (a Link and a Widget) that had overlapping rectangles. *for normal processing* - When the user clicks in a certain point, the interactive PDF processor should walk through the array of annotations on the page dictionary and execute any action(s) associated with the first one that it finds that covers the clicked point. If, however, there is no action to be taken, then move on to see if any more annotations are covering the hit point. Now, beyond that, the processor could do what it wants. For example, support left vs. right clicks. Or support a normal mode and an editing mode. Or .... Why you folks are thinking about this area - don't forget to support QuadPoints for annotation (esp. Link) boundaries. And there is also a proposal in the works at ISO for non-rectangular links (where an arbitrary path can be provided).