|
|
Rank: Advanced Member
Groups: Member
Joined: 7/14/2014
Posts: 40
|
The HTML documents that we need to convert have print media STYLE settings that are not being applied to the conversion. I have learned separately from Jack via e-mail that EO.Pdf uses the screen media STYLE settings and that it's non-trivial to switch EO.Pdf to use the print media STYLE settings instead. As a work around he suggested that I inject some JavaScript that would update the STYLES (and allow us to do a few other tweaks such as resize images) before conversion. As there apparently is currently is no way to inject JavaScript as part of the call to the ConvertUrl method it was suggested that we either load the HTML into a string, append the JavaScript, and pass that string to a ConvertHtml call or use footers on IIS to tack the JavaScript onto the end when calling with ConvertUrl.
Perhaps it's a premature optimization on my part but reading in some rather large HTML files (massive really - 30-125MB) into strings in memory and then tacking on JavaScript to the end doesn't sound all that performant. Nor does adding a dependency on IIS (all the files are on a SAN). As such I've been trying to explore other options and came across HTML5's import functionality. My idea was to have a small "template" HTML string that contains:
STYLE definition - Simple static STYLE to use in lieu of original STYLE definition.
SCRIPT definition - Contains all of the JavaScript that I'd want to use to modify the original document before conversion.
LINK definition - Contains a HTML5 "import" using <link rel="import" src="...">
Where I'd simply replace the value of the link's source attribute with the URL to the file to actually load. I'm able to get a static example working in Chrome and Firefox when I request the file via IIS (locally it doesn't work due to CORS and I haven't figured out how to fix that yet) but I can't seem to get it working at all through EO.Pdf no matter what I try. I'm pretty sure that WebKit supports HTML5's link import. I've tried a number of different options on the link tag as well to no avail.
<!DOCTYPE html>
<html>
<head>
<style type="text/css">
<!-- body { color: purple } -->
</style>
<script type="text/javascript">
function myFunction()
{
// Replace the original BODY with the BODY of the imported content. Imported content not injected into the DOM automatically for HTML.
document.body = document.getElementById("imp").import.body;
// Test STYLE block replacement
document.head.getElementsByTagName("style")[0].innerHTML = "<!-- body { color: orange } h1 { text-align: center } -->";
}
function fubar()
{
console.log("error");
document.body.innerHTML = "FUBAR - If you see this then import failed to load!";
}
</script>
<link id="imp" crossorigin="use-credentials" media="all" type="text/html" rel="import" href="<local path to actual file to convert here>" onload="myFunction()" onerror="fubar()">
</head>
<body>
FUBAR
</body>
</html>
All I see in the output file is FUBAR. It is like it's not even recognizing the import link as if there was a failure to load then the link should have called the fubar() function and I would see a different string displayed in the resulting PDF.
Any ideas of what might be going on/wrong?
Any ideas how to get around the CORS restriction on allowing imports of local files?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
I do not believe our converter supports HTML 5 import. Even with the latest Google Chrome, it is only an "experimental feature" and is not enabled in the release build. So your best option might still be to attach additional JS code to the end of the file.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/14/2014
Posts: 40
|
Yes - you're right it's considered "experimental feature" in Chrome and it's apparently off by default. I thought however that I'd read somewhere that almost all of the browsers have had support for it for some time - however maybe that was referring to inline imports of JavaScript and CSS.
|
|