Just to clarify, I'm not bashing wkhtmltopdf. I think it is a great tool (or at least it was), for what it was initially designed for. I've used it myself several times, to great effect. Albeit mostly long ago (about a decade or so).
I'm not even concerned all that much about the code's state itself, rather that it still shows up today. In situations it was probably never designed for. Adding to that, it now often appears wrapped inside some interfacing layer/code, binding it to whatever other software it is embedded in. But then only exposing part of wkhtmltopdf. Case in point, the --dpi option you mentioned (which indeed might fix the mentioned bug), was simply inaccessible through how the framework interfaced with wkhtmltopdf (which was a design cluster-F# in its own right).
However, the bigger elephant in the room for me is that the HTML/CSS support has changed considerably over the last decade, with wkhtmltopdf pretty much stuck in time. It's just pretty much a random hit or miss when it comes to rendering any modern web content. Only for carefully crafted (legacy) content does it still make a good use case.
I won't blame wkhtmltopdf for that though, but I sure haves questions for those who apparently still consider it a valid tool for integration into modern web frameworks. I guess part of that comes down to unintentional ignorance, not knowing what they are actually integrating. Another reason might be that I've not seen much of a better sort-of-drop-in replacement for wkhtmltopdf, so people stick to it far a lack of a proper alternative. Maybe some of the people who integrated wkhtmltopdf elsewhere are even very well aware of all the limitations/dangers. Still, little use of that if that knowledge is lost on those who subsequently end up using it, primarily just as consumers.
Puppeteer is a very different beast in its own right, regardless which engine/browser you end up using. But if more modern html/css features are required, it can be a valid replacement (regardless of numerous downsides nonetheless). Still, I (also) doubt that it will work as a good replacement for all of wkhtmltopdf's use cases.
If nothing else, I got some free entertainment out of it all .. watching the shocked expression on the faces of top-level suits, when I explained to them what they had been blissfully unaware of. They had good reasons to be worried, because this exposure should have been caught by their rigorous technology-review procedures. However, it had been an ad-hock dependencies that was introduced as part of a legit feature request. The dev had probably never even noticed, because it appeared as a native framework functionality (hiding any obvious reference to using wkhtmltopdf under the hood). Anyways, wkhtmltopdf is certainly not to be blamed for that.
Still, it does illustrate the dangers of modern-day software integration. I think especially in (web) frameworks, where the name of the game often appears to have turned towards a popularity contest (with competing frameworks) and "making things as simple as possible". Something about a road paved with good intentions.
I'm not even concerned all that much about the code's state itself, rather that it still shows up today. In situations it was probably never designed for. Adding to that, it now often appears wrapped inside some interfacing layer/code, binding it to whatever other software it is embedded in. But then only exposing part of wkhtmltopdf. Case in point, the --dpi option you mentioned (which indeed might fix the mentioned bug), was simply inaccessible through how the framework interfaced with wkhtmltopdf (which was a design cluster-F# in its own right).
However, the bigger elephant in the room for me is that the HTML/CSS support has changed considerably over the last decade, with wkhtmltopdf pretty much stuck in time. It's just pretty much a random hit or miss when it comes to rendering any modern web content. Only for carefully crafted (legacy) content does it still make a good use case.
I won't blame wkhtmltopdf for that though, but I sure haves questions for those who apparently still consider it a valid tool for integration into modern web frameworks. I guess part of that comes down to unintentional ignorance, not knowing what they are actually integrating. Another reason might be that I've not seen much of a better sort-of-drop-in replacement for wkhtmltopdf, so people stick to it far a lack of a proper alternative. Maybe some of the people who integrated wkhtmltopdf elsewhere are even very well aware of all the limitations/dangers. Still, little use of that if that knowledge is lost on those who subsequently end up using it, primarily just as consumers.
Puppeteer is a very different beast in its own right, regardless which engine/browser you end up using. But if more modern html/css features are required, it can be a valid replacement (regardless of numerous downsides nonetheless). Still, I (also) doubt that it will work as a good replacement for all of wkhtmltopdf's use cases.
If nothing else, I got some free entertainment out of it all .. watching the shocked expression on the faces of top-level suits, when I explained to them what they had been blissfully unaware of. They had good reasons to be worried, because this exposure should have been caught by their rigorous technology-review procedures. However, it had been an ad-hock dependencies that was introduced as part of a legit feature request. The dev had probably never even noticed, because it appeared as a native framework functionality (hiding any obvious reference to using wkhtmltopdf under the hood). Anyways, wkhtmltopdf is certainly not to be blamed for that.
Still, it does illustrate the dangers of modern-day software integration. I think especially in (web) frameworks, where the name of the game often appears to have turned towards a popularity contest (with competing frameworks) and "making things as simple as possible". Something about a road paved with good intentions.