Local images not displayed in PDF

VaibhavDS19 commented 3 years ago

Hello, I have an HTML file that uses an image in the same folder as the HTML file. I can't get it to be displayed in the PDF, I can get the rest of the page, however. Is there a way to load the image also to the pdf? Due to some constraints, I can't use the load_from_path and load_from_url, so is there any workaround? Thank you.

craigmayhew commented 3 years ago

Could you please share the constraint that stops you from using the functions?

VaibhavDS19 commented 3 years ago

Sure, the constraint is that I can't host it anywhere, localhost only for now, and no matter what I try, it doesn't get past the load_from_path, I even tried with wkhtmltopdf CLI itself but that always gets stuck at 10% too. Not sure why this is happening, I do use it on WSL if that might help.

craigmayhew commented 3 years ago

On WSL I can't get any local images to load e.g. relative or even full paths <img src="file:///exact/path/to/file/img.jpg">

I don't have a linux box handy to test this - but will test it on linux to confirm if this is a WSL specific issue.

craigmayhew commented 3 years ago

I'm experiencing the same issue on linux - this unfortunately looks like a bug and may not have a quick resolution.

VaibhavDS19 commented 3 years ago

Oh, thanks for the quick replies. So I tried to do it on windows but cargo build gives some wkhtml.lib not found error message. I installed using the wkhtml l installer. Is there any other step I should have done? I added the wkhtml installed folder to the path too, so I am not sure. Please let me know how to fix the lib not found error. Thanks.

craigmayhew commented 3 years ago

I'm glad you are trying it, but please be aware that I'm not sure if the "local images not loading" problem will be solved on windows either - this might be a generic bug with this crate or upstream. I haven't had time to look into this further.

The only thing I can suggest for your windows cargo error "wkhtml.lib not found" is that the wkhtml library is not in the system path.

Which installer did you use, and could you paste the exact terminal output you are recieving? There may be something further I can suggest.

VaibhavDS19 commented 3 years ago

Hi, I am getting this error

error: linking with link.exe failed: exit code: 1181 = note: LINK : fatal error LNK1181: cannot open input file 'wkhtmltox.lib' error: aborting due to previous error error: could not compile latexdocs

I downloaded and ran the installer from this site: https://wkhtmltopdf.org/downloads.html

I have also added the following stuff to my path C:\Program Files\wkhtmltopdf\lib; C:\Program Files\wkhtmltopdf\include\wkhtmltox; Since the lib and the headers are in those folders, I assumed it should be linked since it is on the path.

dosmoc commented 2 years ago

I ran into this issue myself yesterday. It looks like libwkhtmltox as of version 0.12.6 blocks access to local files by default. It's possible to allow access to local files by setting a flag. This is an unsafe operation. Modifying the example a little bit would look like this:

use wkhtmltopdf::*;

fn main() {
    let html = r#"<html><body><div>foo</div><img src="file:///home/username/path/to/local/image/file.svg"></img></body></html>"#;
    let pdf_app = PdfApplication::new().expect("Failed to init PDF application");

    unsafe {    
        let mut pdfout = pdf_app.builder()
            .orientation(Orientation::Landscape)
            .margin(Size::Inches(2))
            .title("Awesome Foo")
            .object_setting("load.blockLocalFileAccess", "false") //enable access to local files
            .build_from_html(&html)
            .expect("failed to build pdf");

        pdfout.save("foo.pdf").expect("failed to save foo.pdf");
    }

}

I haven't tested with relative paths, but full paths work for me.

anowell commented 1 year ago

@dosmoc - seems like it would be pretty reasonable to add a safe allow_local_file_access() builder method. I'd be inclined to merge a PR to that effect.

anowell / wkhtmltopdf-rs

Local images not displayed in PDF #14