Hi,

We currently do not test our product in Docker environment. We will see if we can support this in our 2020 release cycle.

Thanks!

Hi,

Our initial 2020 build should be out in about two weeks. However the initial build will not officially support/be tested in Docker environment. After the initial release, we will look into Docker and see if it is possible for us to support it. So we should have a definite answer in a month or two on this issue.

Thanks!

Hi, we're hitting the same problem trying to generate PDF from a docker container using the 20.0.53.0 build, and also using the InitWorkerProcessExecutable method to configure eopw over rundll.


This is a pretty big problem for us. Any update on if/when we might expect this to be resolved?

Thanks
roger

Thanks for that response. It mostly confirms what we've observed, which is that HtmlToPdf.ConvertUrl works with some container images and doesn't work on others.

Our observation is that it works on containers built from windows version 1607 (windows version Version 10.0.14393), even though the container image is microsoft/windowsservercore

Other images we've tried that fail are mcr.microsoft.com/windows/servercore:1809 (windows version 10.0.17763.914), mcr.microsoft.com/dotnet/framework/runtime:4.8 (also an 1809 variant), and mcr.microsoft.com/windows/servercore:1903.

There are two ways we generate HTML. One is to use the HtmlToPdf.ConvertUrl method. The other involves using a WebView to render the page, use its GetHtml method to capture the html for the page, and then use HtmlToPdf.ConvertHtml to generate the PDF. Thing is, the webview.GetHtml is where we lose. It comes back empty in those containers where ConvertUrl would fail, and works in those containers where ConvertUrl would succeed. So, the point is, it appears to be not be the PDF conversion that fails, but the HTML rendering process. Does that sound right?

Can you speak to how the conversion is expected to fail? We've seen varying results. Sometimes a "web view is destoyed". Sometimes an object ref or other exception is thrown. Most times though, there are no exceptions but the PDF (or HTML in the case of webview.GetHtml) just comes back as empty with no indication that anything went wrong.

Also, can you speak to whether the use of HtmlToPdf.ConvertUrl is thread safe and can be called concurrently by multiple threads? It seems to work, but i'd like to confirm that it should be OK and i'm not just getting lucky.

For example, one solution i'm working on is to provide a web service that accepts a url and some PDF options and then does the ConvertUrl to capture the PDF and stream it back to the requester. I limit the total number of concurrent conversions to some number, say 5, in order to limit the amount of memory from blowing out. In general, should this approach be expected to work?

The service is deployed to an azure web site running windows version 6.2.9200 (windows 8.2, build 9200) which should be a supported OS version based on your response. But, even in that environment, i am finding the ConvertUrl works sometimes, and other times does that "works but empty" thing for the same page. This is even when i limit the number of concurrent requests to 1. I need to do a little more follow up here to make sure i don't have some other issue, but i'd like to know if i should generally expect this approach to work or not.

Thanks
roger

Thanks for the detailed response. That is very helpful.
One thing that isn't thread safe on HtmlToPdf is the DebugConsole. I tried to use it for multiple concurrent requests and quickly discovered that it is global.

In my particular situation, fully specifying fonts using @font-face might actually be doable. But, to be clear, would that allow the page to render with the requested font, or to fall back to the one fixed width font that is present on core image? If the former, this might be something i would pursue. If the latter, it probably wouldn't be worth it. Either way, what would help immensely would be if when it failed it produced some diagnostic information like the specific font that was not found. Even better if it knew the css rule and location that failing font.

Thanks
roger

Thanks for sharing the tip ---- all over the Internet says fonts can not be added on Windows Server Core container image, I guess you just proved the Internet wrong. :)

We did test the 2020 version by copying all fonts to the container and it does work.

As to your suggestion about throwing an exception about missing font, this would be nice but is not practical to implement. The issues originates from a check failure inside Chromium browser engine and there are numerous such checks all over among Chromiums over 30 million lines of code. We were able to pinpoint to the exact point of failure by debugging into Chromium's source code. But obviously it is not doable for us to investigate every possible check failure. Nevertheless, your feedback is still extremely appreciated.

Our solution was similar. We use COPY directive inside Dockerfile to copy the fonts over and that works too.

As to the Chromium situation, I hear what you are saying. I wish there was a faster way. But this is in fact what we do every day. Numerous times we spend days and nights debugging into Chromium engine and only to find something so simple. As we spend more and more time debugging the browser engine, we do get better and better at navigating it and narrow down the problems quicker. We appreciate you very much for bearing with us in this process and also working and sharing your findings with us.

We will look into the DebugConsole issue. At present we are not planing to have a separate DebugConsole for each thread because generally a debug console catches output from all threads (think of Visual Studio's debug console). So if we switch it to a per thread model, then then we will have other user asking us to output all debug info to a single console. But we maybe able to add some kind of locking/filtering mechanism so that you only get what you need.

Hi,

Please try the current version first. We did address another issue with Windows Server Core support in 20.2.63.

Thanks!