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

ulr-encoded anchors in OOXML output #408

Open
kappapiana opened this issue Oct 16, 2023 · 2 comments
Open

ulr-encoded anchors in OOXML output #408

kappapiana opened this issue Oct 16, 2023 · 2 comments

Comments

@kappapiana
Copy link

Not sure it's a pandoc-crossref, pandoc or Libreoffice issue, but using internal section references, the resulting ancor in OOXML would point to something like w:name="w:name="sec:sec_sow:a"".

Then I open the document and links work fine

However, if I just save the unmodified document in Libreoffice the : character gets URL-encoded as %3A and results in w:name="sec%3Asec_sow%3Aa" and the internal link gets broken. But since I gather this is something related to compliance, wouldn't it be safer to use the same conversion, since we are dealing with URLs?

@lierdakil
Copy link
Owner

OOXML is docx IIRC, so I'm a little confused about you using Libreoffice. Are you opening docx in Libreoffice, or is the problem with odt output?

In any case, I think this issue would be better solved upstream, there's very little docx-specific code in pandoc-crossref, and I don't think adding more is the solution here.

@kappapiana
Copy link
Author

Yes, I am using LO to open docx/OOXML (within a script, but it's not relevant).

My query was more on why not URL-encode the links anyway. This way it would not be changed and the internal reference will be kept intact. Actually what LO does seems rational, probably even mandated by a standard, since URLs cannot contain colon.

But you are right, it's probably a pandoc issue.

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