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

Support relative file URIs in hyperlinks when using CLI #532

Closed
noverby opened this issue Nov 9, 2017 · 8 comments
Closed

Support relative file URIs in hyperlinks when using CLI #532

noverby opened this issue Nov 9, 2017 · 8 comments
Labels
feature New feature that should be supported
Milestone

Comments

@noverby
Copy link

noverby commented Nov 9, 2017

For example when converting the following html to a pdf, it should be possible to make the hyperlink refer to the relative URI and not the absolute URI:

<a href="external-file.pdf">File</a>

What I get: "file://absolute-path/external-file.pdf"
What I want: "external-file.pdf"

I have tried to change the --base-url argument, but it does not remove the absolute path if I set it to ""(empty).

So I looked it up in the code, and it is fairly easy to change, but I just wanted to make sure that there is interest in including this feature. If there are indeed interest I can make a pull request.

Relative file URIs are also what Prince outputs by default.

@noverby noverby changed the title Support relative file paths in links Support relative file URIs in hyperlinks Nov 9, 2017
@liZe
Copy link
Member

liZe commented Nov 10, 2017

Hmmm… Really looks like #437, I'll take a look.

@liZe liZe added the feature New feature that should be supported label Nov 16, 2017
@liZe liZe changed the title Support relative file URIs in hyperlinks Support relative file URIs in hyperlinks when using CLI Nov 16, 2017
@liZe
Copy link
Member

liZe commented Nov 16, 2017

Unfortunately, what you want is currently impossible using the CLI:

  • HTML finds base_url from the document when using a file,
  • the CLI uses '.' instead of None as default base_url value when using stdin, and
  • base_url is transformed into an absolute path when it's different from None (even if it's '').

Even if these 3 choices may look strange when looked at carefully, I think that they are actually really good when they're used without thinking (and that's what most CLI users do). I don't want to change this behavior.

So you currently have to use HTML(string='<a href="external-file.pdf">File</a>') to get what you want.

A solution would be to transform --base-url="" into base_url = None, and keep base_url = '.' when --base-url is not set. You would then be able to get relative URIs using weasyprint --base-url="" - output.pdf < input.html. What do you think about that?

@noverby
Copy link
Author

noverby commented Nov 16, 2017

@liZe That would be nice. Thank you 👍

@liZe liZe closed this as completed in 3961774 Nov 16, 2017
@liZe liZe added this to the v0.42 milestone Nov 16, 2017
@W4RH4WK
Copy link

W4RH4WK commented Aug 28, 2022

It seems like this does not work anymore.

I reference another PDF via <a href="books/anarchy.pdf"> and even when calling weasyprint with --base-url="" it still writes an absolute path to the PDF.

@liZe
Copy link
Member

liZe commented Aug 29, 2022

It seems like this does not work anymore.

It seems to work for me, when using both --base-url="", and - output.pdf < input.html to give no filename hint.

@W4RH4WK
Copy link

W4RH4WK commented Aug 29, 2022

I see, providing the input via stdin is relevant for this.

With this, the filepath indeed remains relative. However, style sheets are no longer found:

ERROR: Relative URI reference without a base URI: <link href="normalize.min.css">
ERROR: Relative URI reference without a base URI: <link href="style.css">

@liZe
Copy link
Member

liZe commented Aug 29, 2022

However, style sheets are no longer found:

Of course, they’re not found because there’s no base-url.

Handling your use case is not as easy as it looks. Even if we add a new option (something like keep-local-anchors), I think that it will be really hard to find a behavior that satisfies everyone.

If you want to get this feature, you can open a new issue so that we can discuss your use case and find a way to solve it in a quite flexible way. I can’t promise that it will be implemented, as the current behavior is already quite complex (even if it’s easy to use in easy cases, as explained above).

@W4RH4WK
Copy link

W4RH4WK commented Aug 29, 2022

Alright. This is currently not high on my priority list. When I come around to this, I might checkout the code and see whether I can come up with something that is viable. I'll open an issue / PR as necessary.

Thank you for the information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature that should be supported
Projects
None yet
Development

No branches or pull requests

3 participants