Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FR] Provide conditional to test if document is tagged #729

Open
gusbrs opened this issue Oct 10, 2024 · 2 comments
Open

[FR] Provide conditional to test if document is tagged #729

gusbrs opened this issue Oct 10, 2024 · 2 comments

Comments

@gusbrs
Copy link
Contributor

gusbrs commented Oct 10, 2024

I'd like to suggest the provision of a conditional to test whether "the document is supposed to be tagged and the tagging infrastructure (currently provided by tagpdf) is expected to be available". Let's say \tag_if_enabled:TF.

I'm aware, of course, of \tag_if_active:TF, but it falls short for a couple of reasons:

  • The kernel does provide a dummy definition for it, but only at begindocument, so a package cannot count on its existence in the preamble.
  • \tag_if_active:TF tests if tagging is "currently active", depending on \l__tag_active_struct_bool and \l__tag_active_mc_bool which may be toggled by \tag_stop:/\tag_start: and friends. Which is different from "the document is supposed to be tagged".

As use case for motivation, my attempts to add tagging support to postnotes included a number of tasks which must be globally performed as long as the document is intended to be tagged, regardless of current state of "activation" of tagging (of \l__tag_active_struct_bool and \l__tag_active_mc_bool, that is). These are basically a number of cross-references and passing information around from the mark to the note (and back). But these must be available at all times. Suppose someone stops tagging at the place the mark is placed but then turns it on again when the note is supposed to be printed. If the cross-reference is not there, there's no hope the latter will work. (True, in this case, things will likely go wrong for other reasons, but I hope you get what I mean). However, there's also no reason to set these things if the document is not supposed to be tagged at all.

I'm currently testing for:

\bool_lazy_and:nnT
  { \cs_if_exist_p:N \tag_if_active_p: }
  { \tag_if_active_p: }

And expecting no one has any reason to call \tag_stop: in the preamble. But it feels weird...

@gusbrs
Copy link
Contributor Author

gusbrs commented Oct 11, 2024

I just met another use case which may help motivate this (beyond "infrastructure cross-refs"). If a pair of sockets surrounding some content needs to suspend tagging for the length of said content, we cannot use \tag_socket_use:n, but need to rely on \socket_use:n. Hence, the workings of these sockets would depend on the plugs assigned to them, and the plugs with tagging content should be assigned under some condition. And, in my view, the right condition is "if the document is supposed to be tagged". The same general reasoning would apply if we were working with a couple of dedicated functions instead of sockets.

Practical case in hand, latex-lab-footmisc defines \multfootsep to include the tagging code (for reasons, which I'm not questioning). So anyone else trying to add support for such feature meets the situation where the structure of the tagging code depends on whether footmisc is loaded or not. A reasonable thing to do is suspend/resume tagging around \multfootsep, which leads to the situation above. Of course, nothing unique there, \tag_suspend:n and \tag_resume:n exist because they are needed and the tagpdf documentation acknowledges that.

@u-fischer
Copy link
Member

If you need to suspend tagging you should normally do something like

\UseTaggingSocket{...}\SuspendTagging{\endnote} ... \ResumeTagging{\endnote}\UseTaggingSocket . (One could hide the suspend command inside the socket, but it looks more symmetric like this.)

But it sounds wrong to go through some suspend/resume hoops to get around an awkward definition of \multfootsep. I think one should look at what the various packages/classes are doing here and try to find a saner solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants