PDFdev is a service provided by PDFzone.com | http://www.pdfzone.com _____________________________________________________________
I've got a tab-order problem. We've got this customer who has whipped up a beast of a form in our software. 54 pages of some of the densest form I've ever had the misfortune of encountering. I weep for the poor wretches forced to fill it out. But I digress. Our software tags everything with marked content, primarily for accessibility reasons. US Gov't contracts now require accessibility and when we're one of the few companies creating accessible forms, that's a real advantage. Until Acrobat 6 runs face-first into the brick wall that is this form. One of the new page-level keys introduces in the last version or two of the PDF spec is the "/Tabs" key. Its presence or absence can have several meanings: Missing: Use the default annotation order *. <-- note the asterisk R: Row order C: Column order S: Structure order... use the StructParent values to determine tab order. Row and column order are both just fine. Works great. But we have an explicit tab order that we'd like obeyed, and is independant of reading (structure) order. *: In Acrobat 6, they introduced an accessibility-related preference setting "Use document structure for tab order when no explicit tab order is specified". This setting is on by default, meaning that there is an implicit "/Tabs /S" on every page, overriding our desired tab order. More than a little frustrating, all by itself. Yes, people can change that setting, but how many people will ever look at that accessibility setting page, much less know to turn it off (without some prodding on our part, which still won't help some people). And on that monster form, Acrobat 6 is excruciating. Tabbing between fields is painfully slow. The "/ParentTreeNextKey" indicates that there are 3038 different marked content elements. Yow. But I fail to see WHY it's so slow. Sure, there's a lot of MC in there, but so what? Each annotation has a "/StructParent", an integer indicating which structure element to use. AND THEY'RE IN ORDER. Already sorted. Ready to go. So why does Acobat 6 even care how many entries are present when it already has this order at the page level. Frustrating. Acrobat 5 is fine. Snappy as anyone could ask for. All this is on a dual 2.2ghz machine... so I wouldn't expect anything Adobe could reasonably doing could make this beast blink... but there it is. So I tried a couple different guesses at what might fool Acrobat 6 into taking the annotation order, to no avail. I guess I'm hoping for one of two resonses to this email: 1) Someone knows something I don't about some undocumented feature (or a documented one that I missed) that will allow us to either change the user preferences, or trick Acrobat 6 into ignoring our structure. 2) Adobe saying: "Hey, we missed something. We'll introduce a new /Tabs setting in our next patch to explicitly set the tab order to annotation order". Or at least "Wow. That IS slow. We'll speed that up for ya". Any takers? I can make the form available on request. It's a bit over 3 megs. It doesn't SEEM big, does it? --Mark Storer Software Engineer Cardiff Software #include <disclaimer> typdef std::disclaimer<Cardiff> Discard; To change your subscription: http://www.pdfzone.com/discussions/lists-pdfdev.html
