Welcome Guest Search | Active Topics | Sign In | Register

Javascript rendering output intermittent (upgrade from EO.Total.15 to .16) Options
Voicebooth Ltd
Posted: Sunday, July 17, 2016 8:58:29 AM
Rank: Member
Groups: Member

Joined: 7/17/2016
Posts: 17
Hiya,

I've just upgraded my EO.Total package from .15 to .16 specifically in the use of EO.Pdf (latest build as of today 16.1.46.0) as I've been hunting for a solution to CSS and image files being cached in memory.

I render an HTML page that contains some javascript to render a chart. This uses jquery, and utilises the $( document ).ready( handler ) call to render said graph.

I run EO.Pdf as part of a win32 service, and after the upgrade I'm finding that the rendering of the overall page, sometimes just the chart area, sometimes the whole page, is randomly not being given the width they should be.

The PDF file should look like:

http://static.billingbooth.com/files/working.pdf

But I've had things like:

http://static.billingbooth.com/files/whole_page.pdf

And:

http://static.billingbooth.com/files/only_chart.pdf

I've tried fiddling with the MinLoadWaitTime setting but it doesn't seem to make much difference that I can see - the main pattern that I'm seeing is that this happens during the first time the PDF is created once the service is started, which does suggest some initialisation issue.

Any suggestions on how to overcome this problem?


Regards,
Alvaro
eo_support
Posted: Sunday, July 17, 2016 9:35:30 AM
Rank: Administration
Groups: Administration

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

You can try to use manual trigger so that you only trigger the conversion after your JavaScript code has finished rendering the chart. See here for more details:

http://www.essentialobjects.com/doc/pdf/htmltopdf/trigger.aspx

Thanks!
Voicebooth Ltd
Posted: Sunday, July 17, 2016 10:08:47 AM
Rank: Member
Groups: Member

Joined: 7/17/2016
Posts: 17
Hiya,

Thanks for the quick response.

I've had a bit more of a play with it, using the trigger mode, but I'm still getting much the same problem with the overall width of the rendering. Is it possible that rather than being a javascript timing issue (ie not enough time to load), its that the javascript or HTML being rendered is initially rendered to a smaller width, then redrawn afterwards to a bigger size, but sometimes it doesn't have the time to do the second pass?

Using the trigger to manual, I wrote a quick function within my code that looks a bit like this:

Quote:

var count = 0;

function isReady() {
count++;

if (count === 2)
eoapi.convert();
}


This isReady() is bound by the chart's "done" event, and I can see this working fine in HTML, so the sequence of events is correct. However, the output from my test is much the same during the first attempt at rendering a PDF:

http://static.billingbooth.com/files/still.pdf

Looking at one of my previous examples in my first posting, the whole page has the wrong width, even though none of that relates to javascript, it's all purely HTML output.

This is not an issue I had encountered with the old version of EO.Pdf (15), so I'm assuming the change of rendering engine has done something to this.

Is this something that can be investigated?


Regards,
Alvaro
Voicebooth Ltd
Posted: Sunday, July 17, 2016 1:23:01 PM
Rank: Member
Groups: Member

Joined: 7/17/2016
Posts: 17
I've spent the rest of the afternoon trying out different things, but nothing seems to fix the random nature of the problem. I have tried increasing the MinWaitTime to a whole second, I've tried a couple of different approaches using the manual trigger to no avail. My initial observations of this happening during the first render after a service is started are incorrect, it has happened mid-testing too.

After all this testing, I don't believe the problem is directly related to javascript not executing in time, but rather the document width not being obtained from the browser engine correctly.

In the end, I have reverted to using the classic rendering engine which has so far fixed the problem, although sadly my initial problem of stylesheets caching is now back, but it's a small sacrifice to not just output garbage.

It would be good going forward to have an answer or a fix for this problem, since I'm now stuck with what's effectively a legacy rendering engine which I imagine will be made redundant in the future.

Happy to provide full source code of the HTML/javascript involved.


Regards,
Alvaro
eo_support
Posted: Sunday, July 17, 2016 3:52:47 PM
Rank: Administration
Groups: Administration

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

Please send the test project to us. See here for more information:

http://www.essentialobjects.com/forum/test_project.aspx

We will look into it as soon as we receive it.

Thanks!


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.