PDFdev is a service provided by PDFzone.com | http://www.pdfzone.com
_____________________________________________________________

Well, for those of you who are curious, there's been a flurry of off-list
activity.  Sadly, it's been more of the "sound and fury, signifying
nothing"-type activity.  No solutions, workarounds, or soon-to-be-released
patches.

Bah!  Humbug...

--Mark Storer
  Software Engineer
  Cardiff Software
#include <disclaimer>
typdef std::disclaimer<Cardiff> Discard;


> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Mark Storer
> Sent: Monday, December 01, 2003 3:01 PM
> To: [EMAIL PROTECTED]
> Subject: [PDFdev] Tab order in Acrobat 6.0
> 
> 
> 
> 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
> 

To change your subscription:
http://www.pdfzone.com/discussions/lists-pdfdev.html

Reply via email to