|
|
Rank: Newbie
Groups: Member
Joined: 9/3/2011
Posts: 6
|
I'm evaluating your product, and its great but I seem to be having some javascript problems. I am using HtmltoToPdf.convertHtml, and passing in a string that is an entire page. This is in a test environment on localhost, and at least for now- every src tag and href tag is an absolute path. and not a relative path in order to make sure I am absolutely sure every file is being pulled in. I can pull in the CSS, and images with no problem, but I don't believe my external js dependencies are loading. I experience the same issue with setting the baseUrl, too. I wanted to trigger the conversion manually, and that is when i discovered that currently ... Quote:if (typeof(eopdf) == "object")
{
document.write('you're in the eopdf virtual browser');
eopdf.convert();
}
else
{
document.write('you're in real/web virtual browser');
} ... always breaks in to the else statement, so I cannot seem to call eopdf.convert(), when I am set to manual or dual mode. This would be preferable, of course, than by arbitrarily setting a minimum or maximum time, because I could use a javascript callback when I am certain, all the js has truly completed. there could be a javascript error leading up to this, such as if your javascript parser chokes on console.log() or something, but I have no way of knowing just what. is there a way to see what threw an error while inside your 'virtual' browser? Javascript is responsible for much of the viewstate. I feel a bit powerless to see whats going on inside of the javascript engine while htmltopdf is running. If there is an error it has, that my browser does not, I wouldn't know. I am open to any suggestions, thank you for any time or attention you give to my post.
|
|
Rank: Newbie
Groups: Member
Joined: 9/3/2011
Posts: 1
|
<html>
<title>
Mamta
</title>
<body big colour ="pink">
[WARNING FROM ADMIN TO mamtadevi]
Do not post unrelated content in our forum. We will suspend your account if you do it again.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
External JavaScript should load fine as soon as you set BaseUrl correctly.
The "eopdf" JavaScript is only added very recently. So check whether you have the latest version first. The current build has a DLL version number of 3.0.64.2. If your DLL is older than that, you can update to that version and try again.
If the problem still occurs with the latest version, please try to create a small test project that demonstrates the problem and send to us. In that case please let us know so that we can give you the email address.
There is no easy way for you to see what failed to load inside the converter (we can see it in our environment, that's why as soon as we have the sample app, we can tell you what failed). However usually as long as you set BaseUrl correctly, everything should just work.
Thanks!
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
Here is some additional information about BaseUrl:
You do not have to set BaseUrl with build 3.0.64.2 if your src is already absolute path.
With earlier builds, when you use absolute path the value of BaseUrl does not matter --- but you have to set it if your path is file path (instead of http/https path). Setting BaseUrl turns on "local file permission" for the converter. Otherwise the converter will not load local files for security reasons. With the latest build, a new property HtmlToPdfOptions.AllowLocalAccess is added to explicitly control whether local access is allowed (default value is true, so you do not have to do anything).
Thanks
|
|
Rank: Newbie
Groups: Member
Joined: 9/3/2011
Posts: 6
|
Ok, I suspected as much about Base URL, which is fine as I am using absolute paths. (I am using the HtmlAgilityPack with HttpContext.Current.Server.MapPath, to get the exact file location - and I can confirm all my src paths are correct.)
As for the version number,
3.0.64.2 is what I have I just downloaded it last week.
Could you possibly enumerate nay difference between your virtual browser and say, a webkit browser? The site runs properly inside of chrome and firefox, for example - but its dying in the virtual browser environment in eopdf. I am going to continue to debug, and if I discover the 'culprit' I'll let you know.
what might be some appropriate values for HtmlToPdf.MinLoadWaittime and MaxLoadWaittime. I will use these until I an figure out why the eopdf object is not being detected.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
Under no circumstance typeof(eopdf) == "object" should be false in version 3.0.64.2. That should not happen. So if you believe that's what you are seeing, I would recommend you to try to isolate the problem into a small test project and send it to us. We should be able to find out what's wrong right away. Let us know if you wish to do that so that we can let you know where to send the test project.
There is virtually no difference between our "virtual browser" and a WebKit browser. Our "virtual browser" in fact is based on WebKit --- that's why it can handle anything your browser can handle. So if the page runs fine in Chrome and Safari, it should run fine in our browser, all are the same engine. The only important difference is you cannot use "load HTML" with a real browser. When you use a real browser, it always loads from a "Url", either a real network Url or a file. So if you run into problem with "load HTML" with our converter, try save the HTML into a file and compare the result for that file. That should help you to narrow down the problem.
The default MinLoadWaitTime and MaxLoadWaitTime should be good for most cases. If you use AJAX, then you might want to increase MinLoadWaitTime to a few hundreds milliseconds.
Thanks
|
|
Rank: Newbie
Groups: Member
Joined: 9/3/2011
Posts: 6
|
I am willing to send you a test project if you find that to be of use. I will mention that I did manage to get the project working - sort of. I'll explain. in the interest of troubleshooting I returned the Html I was emitting that was supposed to be the Html for the printed PDF. I literally copied and pasted it into an html file (as you suggested), and tried to open it in the browser to see what the problem was. The page looked fine. So, I modified my code slightly. Rather than use ConvertHtml, I am using ConvertUrl (though I'd rather just pass the string). Something like this: Quote:
string remotefilepath = HttpContext.Current.Server.MapPath("~/My absoluteUrl/Temporary.html");
MemoryStream mStream = new MemoryStream(ASCIIEncoding.Default.GetBytes(theEmittedHtml));
WebClient webClient = new WebClient();
webClient.UploadData(remoteFilePath, mStream.ToArray());
EO.Pdf.PdfDocument pdfDoc = new EO.Pdf.PdfDocument();
HtmlToPdf.ConvertUrl(remoteFilepath, pdfDoc);
pdfDoc.Save(outputPathforThePDF);
File.Delete(remotefilepath);
..so this works. The elements of the page affected by JavaScript look alright. You can see I made an html file in memory, and saved it to a temporary location. I then used convertUrl on that location. However, simply running convertHtml on the exact same string I used to make the temp html file doesn't work... Quote:
EO.Pdf.PdfDocument pdfDoc = new EO.Pdf.PdfDocument();
HtmlToPdf.ConvertHtml(theEmittedHtml, pdfDoc);
pdfDoc.Save(outputPathforThePDF);
Of course this grants the same capability, in a way- of converting an HTML string to a PDF, but it would be nice to have a working ConvertHTML method, so there is no unnecessary writing to disk and needless complication. If there is some option I've overlooked involving perhaps passing a Stream or something, that would also be great. I didn't see anything like that in the documentation Why, in your estimation, would HtmlToPdf.ConvertHTML fail, and not HtmlToPdf.ConvertUrl, for the exact same HTML? Just to reiterate, all paths are absolute. Let me know how I can help you shed light on this. I am willing to send a test- but now that I can confirm the converturl method works on the exact same html, i figured that might help you help me. :) let me know what works, thanks :)
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
Thanks for the update. A test project would definitely help. We've sent you a private message as to where to send the test project. You can click the "inbox" at the top of the forum to view the message. As soon as we have the test project, we will look into it and let you know what we find.
Thanks!
|
|