wkhtmltopdf-rs
wkhtmltopdf-rs copied to clipboard
anowell
Inconsistent documentation & code
https://github.com/anowell/wkhtmltopdf-rs/blob/c944f270c3b73c6eb7593b702be69f91f57106ca/src/pdf/mod.rs#L180-L191
https://github.com/anowell/wkhtmltopdf-rs/blob/c944f270c3b73c6eb7593b702be69f91f57106ca/src/image/mod.rs#L70-L78
Documentation states that self is mutably borrowed, while it's actually immutably borrowed. I think it's the code that's incorrect, but I'm not completely sure.
Also the links to https://github.com/wkhtmltoimage/wkhtmltoimage need to be updated to https://github.com/wkhtmltopdf/wkhtmltopdf. Currently they are 404ing.
This used to be the case and was changed in https://github.com/anowell/wkhtmltopdf-rs/commit/810d346264e68456b2b43a9c25d3a89002379148.
The reason why this was changed appears to be that this had no effect with regards to type safety, as the PdfBuilder failed to store that mutable reference somewhere and propagate it to subsequent objects, as it should have.
It should have because that would have been the way to prevent two instances from being there at the same time. There is a detailed article on https://adventures.michaelfbryan.com/posts/pragmatic-global-state/ that explains how to write a such interface. Notably you can see that struct RecipeBuilder captures 'lib to actually "ensure only that one builder is active at a time".
NB: The lifetime on PdfOutput is meaningless as well, probably should be 'static...
All in all, this doesn't give me enough confidence to use this lib given the ratio between noticeable imprecisions and amount of unsafe code :(
NB2: Probably we could rename this issue "fix only-one-instance constraint enforcement"?
All in all, this doesn't give me enough confidence to use this lib given the ratio between noticeable imprecisions and amount of unsafe code :(
Yeah. I initially played around with wkhtmltopdf a bit, but after I noticed several instances when it failed to handle modern-ish CSS I had to admit defeat and go back to using a "normal" webdriver.
Considering the fact that https://github.com/wkhtmltopdf/wkhtmltopdf has seemingly ceased development, I would go so far as to say that anything related to it should be avoided like the plague.
What did you end up using?
This is what I use: https://crates.io/crates/headless_chrome, but my use case is really simple (just taking a screenshot of a webpage), so your mileage may vary. It's worked okay so far.
The nice thing I like about it, is that it will scan for Edge on the system and use it if present, making targeting Windows very painless.
All in all, this doesn't give me enough confidence to use this lib given the ratio between noticeable imprecisions and amount of unsafe code :(
Fwiw, I'm no longer using this crate either (nor any alternative). I did use it successfully in a small production service for a few years, but I've since shut that service down. I've continued to do the bare minimum to accept some PRs, but not much more. I would entertain transferring it if there was demonstrated effort to maintain it. That said, I can't attest much to the upstream wkhtmltopdf other than to say it felt barely maintained when I started this project.
(As a side note: "the amount of unsafe code" is basically necessary for a library that is just a wrapper for a C lib.)
Documentation states that self is mutably borrowed, while it's actually immutably borrowed. I think it's the code that's incorrect, but I'm not completely sure.
I don't recall my decision process, but fwiw, this was an intentional change at some point (and the doc wasn't updated):
https://github.com/anowell/wkhtmltopdf-rs/commit/810d346264e68456b2b43a9c25d3a89002379148