Welcome Guest Search | Active Topics | Sign In | Register

Margins getting reset between a ConvertHtml and RenderAsPDF Options
Brad Mathews
Posted: Friday, September 15, 2017 1:35:13 PM
Rank: Advanced Member
Groups: Member

Joined: 6/19/2013
Posts: 38
I am converting html using ConvertHtml and then later in the same function converting some html using RenderAsPDF.

On some html the margins get reset before the RenderAsPDF and I end up with a page with a long skinny output area. This is not intermittent, if a file works it always works and if a file fails, it always fails.

If I reset the HtmlToPdf.Options between calls then the problem goes away.

I am sending you a test project on this.

- Brad
eo_support
Posted: Friday, September 15, 2017 3:15:17 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi,

This is normal. You should set HtmlToPdf.Options before every conversion in an ASP.NET application. This is because the options are maintained per thread --- so that one thread setting these options would not overwrite options used by another thread. This is important in a multi-thread environment such as an ASP.NET application. Since ASP.NET may use different thread to serve request every time you request, you are actually using multiple instances of HtmlToPdfOptions objects. The best way to avoid any kind of problems for such case is to set it every time.

Thanks!
Brad Mathews
Posted: Friday, September 15, 2017 3:25:50 PM
Rank: Advanced Member
Groups: Member

Joined: 6/19/2013
Posts: 38
Ok, that makes sense.

I used to pass my options into ConvertHtml as that seemed better than relying on global config settings. But I am now also using RenderAsPDF and there did not seem to be a way to pass options to it.

However, I just poked around the docs a bit more thinking that you would not have left a hole like that if the global options were that unreliable, and finally see that I can pass options one step up the stack when I instantiate the HtmlToPdfSession.

- Brad
eo_support
Posted: Friday, September 15, 2017 4:50:05 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi,

The global options are not unreliable. They are just per thread and it is designed that way on purpose. This is standard practice for "global" variables. For example, Windows' GetLastError function always returns the last error of the calling thread. Standard CRT global variables are maintained per thread too. Maintaining a separate copy per thread is the best way to make it reliable to you when you use them in a multi-thread environment. You could declare a "true" global global variable in your own code and then modify it from multiple threads, you will run into all kind of strange issues due to the fact a variable used by one thread can be modified half way by another thread, that is the real "unreliable" situation that this design meant to avoid.

Thanks!
Brad Mathews
Posted: Friday, September 15, 2017 5:28:16 PM
Rank: Advanced Member
Groups: Member

Joined: 6/19/2013
Posts: 38
Ok, maybe "unreliable" was the wrong term, but I went back to supplying a predefined options object to each conversion which I would imagine is a best practice.

- Brad
eo_support
Posted: Friday, September 15, 2017 5:59:24 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
The global variable is easy to use for simple cases. Using an option object to each conversion is more suitable for advanced cases like yours. That's why we provide both.


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.