I'm noticing some inconsistent behavior with EO.Pdf (v5.0.87.2). I'm reading the HTML file to convert into a string buffer and then appending another file (containing Javascript that I want to execute in order to modify the HTML before printing) and then calling HtmlToPdf.ConvertHtml(). This was failing (even though it works in the browsers) with various error messages and so I was trying to determine why by cutting down my script file and then trying to reinstate content until it fails (i.e. divide and conquer).

What I've discovered while doing this though is inconsistent behavior in that for a given fixed input file and script file, successive executions of my test application give me one of three different results!

Result #1
[0.00:00:00.0010] 461753 bytes of content from file: C:\Temp\Test.html
[0.00:00:00.0020] 3076 bytes of content from footer: C:\Temp\Footer.js
[0.00:00:00.0020] 464829 total bytes to convert...
[0.00:00:35.0600] Conversion Completed!

Result #2
[0.00:00:00.0000] 461753 bytes of content from file: C:\Temp\Test.html
[0.00:00:00.0010] 3076 bytes of content from footer: C:\Temp\Footer.js
[0.00:00:00.0010] 464829 total bytes to convert...
[0.00:00:28.0266] EO.Pdf.HtmlToPdfException: Convertion failed. Unable to read beyond the end of the stream. ---> System.IO.EndOfStreamException: Unable to read beyond the end of the stream.
at System.IO.MemoryStream.InternalReadInt32()
at EO.Pdf.Internal.bg.a(Byte[] A_0, Single A_1, Single A_2, Single A_3, Single& A_4, Double A_5, Double A_6)
at EO.Pdf.Internal.lu.a(String A_0, Single& A_1)
at EO.Pdf.Internal.lu.d()
--- End of inner exception stack trace ---
at EO.Pdf.HtmlToPdfException.b(Exception A_0)
at EO.Pdf.Internal.lu.d()
at EO.Pdf.HtmlToPdf.ConvertHtml(String html, PdfDocument doc, HtmlToPdfOptions options)
at ProblemWithAppendingScript.Program.Main(String[] args) in c:\Projects\Source\ThrowAways\ProblemWithAppendingScript\Program.cs:line 81

Result #3
[0.00:00:00.0000] 461753 bytes of content from file: C:\Temp\Test.html
[0.00:00:00.0010] 3076 bytes of content from footer: C:\Temp\Footer.js
[0.00:00:00.0010] 464829 total bytes to convert...
[0.00:00:24.2613] EO.Pdf.HtmlToPdfException: Convertion failed. This session is no longer valid. If you wish to reuse the session later, please consider calling GetCookies to retain the session cookies, then reuse these cookies through HtmlToPdfOptions.Cookies with another session. (5) ---> EO.Pdf.Internal.k0: This session is no longer valid. If you wish to reuse the session later, please consider calling GetCookies to retain the session cookies, then reuse these cookies through HtmlToPdfOptions.Cookies with another session. (5)
at EO.Pdf.Internal.ln.l()
at EO.Pdf.Internal.ln.a(a A_0)
at EO.Pdf.HtmlToPdfSession.a(a A_0)
at EO.Pdf.Internal.lu.a(String A_0, Single& A_1)
at EO.Pdf.Internal.lu.d()
--- End of inner exception stack trace ---
at EO.Pdf.HtmlToPdfException.b(Exception A_0)
at EO.Pdf.Internal.lu.d()
at EO.Pdf.HtmlToPdf.ConvertHtml(String html, PdfDocument doc, HtmlToPdfOptions options)
at ProblemWithAppendingScript.Program.Main(String[] args) in c:\Projects\Source\ThrowAways\ProblemWithAppendingScript\Program.cs:line 81

I've also noticed that if the last statement in the JavaScript ends with a semi-colon (;) character, in addition to the three results above, I've also seen a fourth result as well:

Result #4
[0.00:00:00.0000] 461753 bytes of content from file: C:\Temp\Test.html
[0.00:00:00.0010] 1955 bytes of content from footer: C:\Temp\Footer2.js
[0.00:00:00.0010] 463708 total bytes to convert...
[0.00:00:24.9204] EO.Pdf.HtmlToPdfException: Exception of type 'System.OutOfMemoryException' was thrown.
at EO.Pdf.HtmlToPdfException.b(Exception A_0)
at EO.Pdf.Internal.lu.d()
at EO.Pdf.HtmlToPdf.ConvertHtml(String html, PdfDocument doc, HtmlToPdfOptions options)
at ProblemWithAppendingScript.Program.Main(String[] args) in c:\Projects\Source\ThrowAways\ProblemWithAppendingScript\Program.cs:line 80

My test application is built with VS2012 targeting .NET 4.5, Any CPU (uncheck Prefer 32-bit) and run on Window 7 64-bit.

I will follow this post with an e-mail containing the test project as I know that you'll need this to try and reproduce the errors.

The HTML file alone must be just under the memory limits then as I could never get it to crash if I didn't tack on any script at all...

The irony here is that the [full] script is being added in part to actually scale down any images wider than 2x the page width. We don't author most of these files so we don't have control over the files. I noticed for some files that the text was scaled down way too much due to ridiculously wide images and brought this up with Jack via e-mail previously. He suggested the JavaScript approach to check image sizes and resize.

Any suggestions as to another alternative?

Any way to say add a new HtmlToPdfOptions that would say pass to the browser a max screen width to cap rendering?
Or maybe add a "HtmlToPdfAutoFitMode.ShrinkToFitIgnoringImages" that would scale based on non-image widths?

...

Increasing the MinWaitTime isn't going to help here. The footer in the test project that I sent via e-mail did not even have all of the code in it and wasn't actually even getting called to be executed...

What about a new setting to cap max screen width? Would that be possible? That would keep the buffers smaller and at least allow the rest of the document to be reasonably layed out/rendered/resized. Content over that max would still get resized as part of the shrink to fit but whatever doesn't actually fit on the page would just "fall off the page".

It's never "as simple as" :)

I just didn't know what information you pass down to the engine to start with - i.e. maybe some dimensions of a "virtual" browser window - that might be able to be exposed/controlled. Something like that would allow most of the content to stay constrained within a reasonable limit and then that limit would be the upper bound to use in the fit calculations as well.

I'd had some discussions about this previously via e-mail but it was focused on limiting the zoom/fit. That wouldn't work in this case because the layout of the HTML is using the whole width of these crazy wide images - so limiting zoom wouldn't be effective as lots of textual content would have fallen off.

Whereas this is more about limiting the "virtual window" that the engine is using for layout/rendering to so that the layout/rendering is more reasonable (and then letting the rest fall off) and the resulting fit therefore doesn't have to do some crazy zoom/scale factor to get the contents to fit the page (excluding the crazy wide images).

Actually what it's currently doing is stuffing 10 people into a 4 person car. I just want the car to fit 4-6 people even though 10 want to climb in... those other four people just have to wait.

Issue closed.