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.

Sign up for GitHub

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

Jump to bottom

No way to control xdvipdfmx PDF named destination rewriting #367

Open
pkgw opened this issue Apr 12, 2019 · 3 comments
Open

No way to control xdvipdfmx PDF named destination rewriting #367

pkgw opened this issue Apr 12, 2019 · 3 comments

Comments

@pkgw
Copy link
Collaborator

pkgw commented Apr 12, 2019

xdvipdfmx has a feature that removes unused "named destinations" in the PDFs it generates, implemented by tracking "gotos" here. In the course of doing this it also rewrites the names of these destinations to be sequential integers.

Sometimes, though, you want your output PDF to include named destinations that you specify. This functionality can be enabled by initializing xdvipdfmx with an option named NO_DEST_REMOVE (implemented here).

However, Tectonic provides no way to control this flag (here). We should add one. There's also a question as to what the proper default is.
@sneakers-the-rat
Copy link

1 this, breaks the use of xr-hyper in particular, which expects the references to be named as they are in the .aux file. imo the proper default is to leave the named destinations as-is, as hyperref itself provides means of rewriting/controlling the destination names (and it took me a long time to figure out that it was xdvipdfmx that was rewriting the targets, not anything under my control), and the names generated by hyperref are the "expected" names for the destination both by people and by reliant packages.

@vlasakm
Copy link
Contributor

vlasakm commented Oct 16, 2022

Packages can disable the destination rewriting with \special{dvipdfmx:config C 0x0010}, hyperref already does. With #953 Tectonic will also support it. AFAIK we would be following upstream here (with regards to the default).

Is there anything else to do?

@pkgw
Copy link
Collaborator Author

pkgw commented Oct 21, 2022

@vlasakm This is all a bit of a hack, but based on your analysis, I think there is not more to do! I was thinking of adding a -Z unstable option to provide this feature, but the \special should do the trick. And it is a bit more correct in a certain sense since the document "knows" whether it needs/wants original destination names, so the setting should occur in the document source.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@pkgw @vlasakm @sneakers-the-rat