From: Hans Hagen <pragma@wxs.nl>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: Accessibility and Tagged PDFs: Bugs and Feature Requests
Date: Mon, 06 Jul 2015 10:01:35 +0200 [thread overview]
Message-ID: <559A35DF.8060208@wxs.nl> (raw)
In-Reply-To: <BLU436-SMTP849828D44A16073C02C26F4940@phx.gbl>
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 <pragma@wxs.nl> 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
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___________________________________________________________________________________
next prev parent reply other threads:[~2015-07-06 8:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-03 8:12 Dominik Klein
2015-07-03 17:19 ` Hans Hagen
2015-07-04 16:45 ` Alan BRASLAU
2015-07-05 11:11 ` Hans Hagen
2015-07-05 20:04 ` Dr. Dominik Klein
2015-07-06 8:01 ` Hans Hagen [this message]
[not found] <mailman.1.1435831202.18251.ntg-context@ntg.nl>
2015-07-03 13:16 ` Christoph Reller
2015-07-03 17:09 ` Hans Hagen
-- strict thread matches above, loose matches on Subject: below --
2015-07-01 6:08 Christoph Reller
2015-06-28 10:59 Dr. Dominik Klein
2015-06-30 8:32 ` luigi scarso
2015-06-30 9:00 ` Alan BRASLAU
2015-06-30 15:58 ` Dominik Klein
2015-06-30 16:02 ` luigi scarso
2015-07-01 15:51 ` Hans Hagen
2015-07-01 16:47 ` Hans Hagen
2015-07-01 17:02 ` Hans Hagen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=559A35DF.8060208@wxs.nl \
--to=pragma@wxs.nl \
--cc=ntg-context@ntg.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).