|
|
Rank: Newbie
Groups: Member
Joined: 7/10/2012
Posts: 5
|
We are hoping to upgrade to EO.PDF from a competitor product which uses mshtml.dll as it's rendering engine. However we have seen a few weird display issues where the text is bigger or bolder in the PDF causing the last word to wrap where it shouldn't. It looks fine in Chrome so please find attached an example with the html, css and PDF output. https://docs.google.com/open?id=0B_6CTLuZWmNXTjZwMlQtWm5kWWsWe have set these options, but commenting them out makes no difference: HtmlToPdf.Options.AutoAdjustForDPI = false; HtmlToPdf.Options.AutoFitX = HtmlToPdfAutoFitMode.None; Hopefully there is something blindingly obvious which we are not doing. Any assistance would be gratefully received.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,195
|
Hi,
Thanks for posting in the forum. We can see the difference but we do not know what's causing it yet. We are still looking into it and will let you know as soon as we find anything.
Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 7/10/2012
Posts: 5
|
Thanks for looking into this. I've stripped down the example and I'm (sort of) glad to say it's not our css that's causing the issue. Attached another very stripped down html with inline css showing the same issue which you may find useful. https://docs.google.com/open?id=0B_6CTLuZWmNXczNyU0VPU0FfQlE
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,195
|
Hi,
Thanks for the additional file. We have done the same as well and we are aware that it has nothing to do with your CSS. However we still do not know what's causing it yet. We will reply again if we have any update.
Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 7/10/2012
Posts: 5
|
Has there been any progress on this issue? Is it looking like it could be fixed or is it something horribly complicated? Thank you.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,195
|
Hi,
I aplogize for the delay. We have looked into the issue and it appears that our rendering is correct and Chrome is wrong. As a test, you can run the same HTML through IE 9 and you will see IE 9 produces the same result as we do.
The root of the problem is rounding errors, with both Chrome and IE 8 round a letter’s width down to exact pixels before rendering the whole line. However we do not round them down first. IE 8 used to round them down first, IE 9 no longer does that.
As an example, letter "t" in font Verdana has a base width of 0.4556. "Base width" is the width information stored in the font file that specifies the width of the letter when font size is "1". As such when font size is 12px, the letter's width is 0.4556 * 12 = 5.4668px, when font size is 19px, the letter's width is 0.4556 * 19 = 8.6558px.
If you let Chrome or IE 8 to render 10 "t"s at 12px, then it would first round 5.4668 (0.4556 * 12) down to 5, thus the total length for 10 "t"s at 12px would be 50 pixels. When we render the same content, we take the 5.4668 value and have a total length of 54.668 pixels, which we then round down to reach a total length of 55 pixels. In this case, our output is wider than Chrome's.
However if you try the same font at 19px, then Chrome would first round 8.6558 (0.4556 * 19) to 9, thus the total length for 10 "t"s at 19px would be 90 pixels. When we render the same content, we take the 8.6558 value and have a total length of 86.558, which we then round down to reach a total length of 87 pixels. In this case, our output is narrower than Chrome's. As you can see in both cases our value is more accurate the Chrome’s.
As you can see, different browsers can interpret the same text with very subtle difference and produces noticeable different result when you hard code layout the way you did. So I would recommend you to avoid hard coding it if possible. If you have to, you might want to verify it with multiple browsers. In this case, our calculation is more accurate so you may want to adjust your HTML to reflect the more accurate values.
Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 7/10/2012
Posts: 5
|
Oh dear. Thanks for the detailed reply. I was relying on your assertion that "Rendering any Url, HTML file or HTMl text the same as way your browser does but output as PDF" [sic] as found on your product page. Unfortunately we have over 30,000 dashboards that have been built this way by our clients so we really can't start tweaking the html.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,195
|
Robert Allen wrote:Rendering any Url, HTML file or HTMl text the same as way your browser does but output as PDF We are not exaggerating on that. But you have to understand that even main stream browsers will render things differently. In this case clearly our rendering is more accurate and you will find IE 9 render it the same way as we do. So your HTML files are already invalid on IE 9. I would think sooner or later Chrome would follow and break all your HTML files as well (We use the same engine as Chrome but our output layer is different as we need to output to PDF). So we can't really change our product to produce the output you were expecting. Sorry about that.
|
|