PuppeteerSharp VS CefSharp

PuppeteerSharp

Otherwise, any pdf to hml chromium based solution hosted via docker, like gotenberg](https://github.com/gotenberg/gotenberg) or browserless.io(which is free if you create open source). Generating pdfs from html directly in .NET was always a pain. Wkhtml (and wrappers that use it) uses WebKit and comes with a load of issues of its own, similar to running and styling anything in Safari. Using chromium based engine saves a lot of time as it's the most popular way of doing it these days. You can also use puppeteer-sharp with local chromium if you host your app on something that allows it(f.e. not Azure Functions).

Puppeteer Sharp is a port of the popular Headless Chrome NodeJS API built by Google. Puppeteer Sharp was written in C# and released in 2017 by Darío Kondratiuk to offer the same functionality to .NET developers.

there is a dotnet package for using headless chrome: https://www.puppeteersharp.com/ its a port of the nodejs package of the same name

For the actual conversion of html to pdf we use PuppeteerSharp (https://www.puppeteersharp.com ) but you need browserless for that, which requires an api key (don’t know the pricing)

The README in the GitHub site has been good enough for me: https://github.com/hardkoded/puppeteer-sharp

Iv'e been using https://github.com/hardkoded/puppeteer-sharp for html to pdf conversion for quite some time with success. (in both .net framework and .net core)

Just generate HTML and use https://github.com/hardkoded/puppeteer-sharp to produce a PDF from headless Chrome.

Another idea is to maybe generate the document as HTML first and then convert the HTML to a PDF (with somehting like PuppeteerSharp. I have found this more flexible in the past, but I have not personally done with with nested tables.

The Fullscreen Chromium (cefsharp) based Web-Browser ignores optionally user input like Mouse clicks, and is optionally always in the foreground (Force-Top-Most), so it can be used for any situation.

Just as a background: I'm working on a façade for the CefSharp utility. This utility requires the programmer to initialize and terminate it in the same thread, once-per-process. My current implementation uses a lazy initialization algorithm requiring inter-thread communication. But the possibility of AppDomains arising or passing away complicates the algorithm by requiring threads to potentially signal one another across AppDomain boundaries. It would be easier to just let the threads communicate without worrying about which AppDomain they belonged to.

I dont want to state the obvious but of course there is CefSharp .. But of course thats pretty heavy duty as you end shipping a headless version of Chrome in your app, but it can do anything a browser can do (of course it can, its Chrome), including exectuting a JavaScript string on the fly and getting a response. Because its Chrome you evenn have access the the dev tool and everything like that. But the other suggestions might be better suited as they might be more lightweight.

Two options: Either use an embedded browser you can control programmatically like CefSharp (https://cefsharp.github.io/) or spawn a real browser and use sendkeys() to control the browser by emulating user input.

Chrome Runtime discussion in CefSharp repository.

https://github.com/cefsharp/CefSharp/ if i spiked your intrigue

CefSharp

I always use https://cefsharp.github.io/