Links being resolved to absolute file paths instead of relative

[Kenji776]

When using mdpdf on some generated markdown, the links to other files are always being converted into absolute file paths instead of relative. This is one a windows 10 machine where the current directory is the same as the files being processed. I have attempted to use the suggested fix of prepending ./ before the target (another PDF file) and it still resolves to an absolute path.

Example Markdown
[StripeAgreement](./Stripe-Integration/StripeAgreement.pdf)

Becomes

file:///C:/Users/MyUsername/Documents/SFDX%20Projects/Project%20Sandbox/ApexDoc/docs//Stripe-Integration/StripeAgreement.pdf

This is when mdpdf is being called from within the same folder as the source markdown file. I do notice it seems to be including an extra slash between the root folder that the source markdown file exists in and the sub folder where the related PDF lives. I don't know if that is in anyway meaningful or useful, but it is a little odd.

Is there anything else I can try, or somewhere I could begin looking on my own for how to fix this if you don't have time? Thank you for your time. Great project and even with this issue I still am really impressed and thankful to have it.

[BlueHatbRit]

Hi @Kenji776 - so the code actually attempts to verify image links and convert them to an absolute url:

mdpdf/src/utils.js

Line 56 in 5bcedea

function qualifyImgSources(html, options) {

MDPDF does a 2 stage conversion: markdown -> html -> pdf, in the past we had some trouble with the html -> pdf step where it wasn't rendering relative links and would only accept fully resolved ones. At least that's what I'm remembering, it's been a while!

There are a couple options to change this:

1. I think I did this back before we were using Puppeteer for the html -> pdf conversion, there's a chance we can just remove it and it'll still work. Changing the above linked function to just return the html it's provided should be an easy way to test this through both the CLI or JS API. If we can test it in a few different scenarios and it's no longer needed, we could just ditch it entirely.
2. If it's only needed in some circumstances we could add a toggle to disable resolving image links.

That's all assuming that puppeteer will accept a relative link for a render in the first place, it's hard to tell but we'd have to give it a test with the approach in option 1 above to know.

Unfortunately I don't really have much time to be working on mdpdf these days, I'm happy to review, help debug a bit, and merge/release an update but I don't have the time to sit down and do this myself right now.

Thanks for the kind wording of the issue as well, sometimes they're not worded in such a nice way! Glad you're finding mdpdf useful :)

[Kenji776]

Hey @BlueHatbRit thanks for the prompt reply and thanks for the suggestions. I think I'm a little confused because that code is referencing img links but in my case I'm trying to link to a separate PDF document (my little project automatically creates a series of PDF documents for code documentation with each PDF relating to a different source code file). Not sure if that changes anything but just glancing it seems that function you posted relates specifically to images. Any thoughts?

[nopeless]

@Kenji776 This is not possible because file:// protocol does not allow relative links. I did a little digging and found out that there aren't easy solutions to what you posted.

However, I suggest you that you host these pdfs on a website for example using GitHub so you can always use absolute links using web uri, without having to worry about the recipient's file structure.

[pgalbavy-itrs]

I've run into this and also a slightly related issue - which is more enhancement and happy to open a new issue for it.

I have references to external MD files (generated automatically from my source for each command in the program) and I noticed this problem with relative links but also thought it would be good to maybe have an option to rewrite .md hrefs to .pdf in anticipation of the other files also being converted.