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

subcaption tricks zref-titleref #21

Open
gusbrs opened this issue Aug 22, 2024 · 3 comments
Open

subcaption tricks zref-titleref #21

gusbrs opened this issue Aug 22, 2024 · 3 comments

Comments

@gusbrs
Copy link

gusbrs commented Aug 22, 2024

Currently, the subcaption package seems to defeat zref-titleref for the caption names:

\documentclass{article}

\usepackage{zref-user}
\usepackage{zref-titleref}
\usepackage{subcaption}
\usepackage{hyperref}

\begin{document}

\section{Section}

\begin{table}
  Table
  \caption{Table}
  \label{tab:table}
  \zlabel{tab:table}
\end{table}

\end{document}

Produces the labels:

\newlabel{tab:table}{{1}{1}{Table}{table.caption.1}{}}
\zref@newlabel{tab:table}{\default{1}\page{1}\title{Section}}

Edit: Changing the respective load order changes the above results. If there are consequences of doing so for subcaption functionality, I don't know. If this indeed just a "load order issue", perhaps documenting it in the manual would be useful.

Edit 2: As far as I can tell from just reading code, this seems to be a load order issue. Also:

  • I think the redefinition of \@caption is coming from caption which is loaded by subcaption.
  • Considering how the patches are done zref-titleref it seems to expect to be loaded very late in general, not just for this particular interaction. If the above diagnostics are correct, again, a mention in the docs would be welcome. And just that would be sufficient.
@u-fischer
Copy link
Contributor

Yes changing the order helps.

But generally I think zref-titleref is (now) flawed. Instead of using its own command to store the title (\zref@titleref@current) and patching lots of external commands so that they update the title info it should use \@currentlabelname and make use of nameref. That would mean it would also support the growing number of packages and classes where commands set \@currentlabelname directly.

@gusbrs
Copy link
Author

gusbrs commented Aug 22, 2024

But generally I think zref-titleref is (now) flawed. Instead of using its own command to store the title (\zref@titleref@current) and patching lots of external commands so that they update the title info it should use \@currentlabelname and make use of nameref. That would mean it would also support the growing number of packages and classes where commands set \@currentlabelname directly.

I can only concur. That would be awesome, of course. ;-)

@gusbrs
Copy link
Author

gusbrs commented Aug 22, 2024

An idea, in the spirit of "the least possible fuss": provide a zref-nameref module which simply does:

\zref@newprop{name}{\@currentlabelname}
\zref@addprop\ZREF@mainlist{name}

Since \@currentlabelname is ensured by the kernel anyway nowadays, this is safe regardless of the presence of nameref. If nameref is loaded, it should just work, shouldn't it?

And not much to worry also if anyone around is relying on specific stuff from zref-titleref.

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

No branches or pull requests

2 participants