Re: [NTG-context] Accessibility and Tagged PDFs: Bugs and Feature Requests

On 7/5/2015 10:04 PM, Dr. Dominik Klein wrote:

Am 05.07.15 um 13:11 schrieb Hans Hagen:

...

On 7/4/2015 6:45 PM, Alan BRASLAU wrote:

...

On Fri, 3 Jul 2015 19:19:58 +0200 Hans Hagen wrote: sure but in the meantime we need to find a way to determine what works and what not, for instance, as i mentioned that context already adds a rolemap

11 0 obj << /ParentTree 12 0 R /K 29 0 R /RoleMap << /sectiontitle /H /section /Sect /sectionnumber /H /document /Div >> /Type /StructTreeRoot >> endobj

we have no way to check if that works (so maybe we need to have a page on the wiki with a viewer/functionality matrix)

The whole rolemap thing and how Acrobat Pro handles it leaves me somewhat puzzled.

Taking https://github.com/asdfjkl/tex-access/blob/master/rolemap.tex and compiling will give the rolemap as Hans described above. Looking at the Tag structure, this seems to be ignored by acrobat (but why?), see https://github.com/asdfjkl/tex-access/blob/master/rolemap.PNG

i always suspect a chicken-egg issue there: someone wants a feature, it gets added to pdf, then there is waiting for some typesetting engine to support it, and then acrobat might do something with it and afterwards the spec gets adapted (or interpretation is adapted) .. it happened with widgets and such the interesting thing about tex is that we can easily adapt to such new features but have no way of testing it (some relates to the fact that pdf is both a document format and a storage format for e.g. illustrator so it's some hybrid) maybe it's just: if we have tags it is accessible by definition, no matter if it can be used or not

What would be expected is this, right? After all, the rolemap should be interpreted, shouldn't it (mapping /H to /H1 was a mistake of mine, but it doesn't change the fact). https://github.com/asdfjkl/tex-access/blob/master/rolemap2.PNG After changing things manually in the tag editor in acrobat, and saving the pdf again, this is obtained: https://github.com/asdfjkl/tex-access/blob/master/rolemap_edited.pdf

maybe the H etc is only used with reflow ... and reflow is weird in itself as one can then better provide an html file alongside the pdf it makes me wonder how a complex doc with mostly H's would look / be interpreted as that is then the dominant structure thing

Note this: << /RoleMap << /document /Div /sectionnumber /H /sectiontitle /H /section /Sect >> /Type /StructTreeRoot /ParentTree 12 0 R /K 29 0 R >>

and also the different structure elements at the start of the pdf...

the order of /Key values in the dicts is not important and hashes are often unordered (different per application or even per run for some applications for security reasons); when you play with widgets you will also observe that acrobat adds rendered content to the file as addition to the key/values Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------