|
|
Rank: Advanced Member
Groups: Member
Joined: 5/14/2013
Posts: 45
|
When using Html2PDF with the AutoFitX option ShrinkToFit the generated PDF is just blank for some URLs. The PDF does not appear to be empty (using the mouse content can be selected on the PDF) but appears to be empty/blank. Steps to reproduce: 1. Use EO.PDF Html2PDF function for the following URL: http://www.parlament.ch/d/dokumentation/berichte/Seiten/default.aspx2. Try with the Options AutoFitX None, ScaleToFit and ShrinkToFit. The first two work fine, the third produces a blank PDF file. See the following examples (generated with latest EO.PDF version 5.0.82.2): https://dl.dropboxusercontent.com/u/1776128/AutoFitXPosibilities.zipWe used the following test-tool to create the PDF-Files: https://dl.dropboxusercontent.com/u/1776128/eo-test-tool.zipThis has currently happened for 3 different URLs. One customer intranet, the URL above and one more customer URL. ShrinkToFit is an important option for us, as it is important that the entire page is displayed on the PDF (as you can see without this option, the PDF only shows part of the PDF). Best regards, Simon
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Hi,
Please download the latest build from our download page. I believe this was an issue but it has already been fixed in the current build.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 5/14/2013
Posts: 45
|
Hi,
the error is still there. You can easy reproduce that using our test tool (or just use default EO.PDF options) and the URL I provided.
The behavior is different though:
1. With ShrinkToFit, it creates a PDF now with visible content, but not shrinked (i.e. it's not properly scaled)
2. With ScaleToFit (the option we use - most perfect match regarding screen width) it is still empty.
Best regards,
Simon
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Hi,
Please try to remove overflow-y="hidden" from your body element and see if it works. In order for ShrinkToFit to work property, the HTML to PDF converter must get the "natural" width of the page, which is the page's size when overflow is off. When overflow-y is on, overflow-x is automatically set to "auto", that will prevent the converter from properly getting the page width, which eventually caused the blank page.
We are also changing our code so that even when the root element has overflow on, it will still render the page. ScaleToFit will not work properly in this case since the converter has no way to know the natural width of the page when the root body element has overflow on. However that will at least render something, which should be better than rendering a blank page.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 5/14/2013
Posts: 45
|
Hi, Quote:We are also changing our code so that even when the root element has overflow on, it will still render the page. ScaleToFit will not work properly in this case since the converter has no way to know the natural width of the page when the root body element has overflow on. However that will at least render something, which should be better than rendering a blank page. that would be great. As you may remember from my former posts, we do not control the pages we render. I.e. we cannot impede them to make changes on their pages or page layouts. Quote:Please try to remove overflow-y="hidden" from your body element and see if it works. In order for ShrinkToFit to work property, the HTML to PDF converter must get the "natural" width of the page, which is the page's size when overflow is off. When overflow-y is on, overflow-x is automatically set to "auto", that will prevent the converter from properly getting the page width, which eventually caused the blank page.
But at least now we know what is the origin of the issue. We will try to react ourselves on that property too and trying to remove it, if set. That will require parsing the CSS for body-Tag properties, which is quite an expensive operation. We will also have to do some research, how the pages look like, when the property has been removed (as in most or at least some of the pages it was probably added intentionally). Please tell me, when the converter will still render something if it is not able to determine the width. A fallback on AutoFitX = None in case the width cannot be determined would certainly be good. I could not agree more on "However that will at least render something, which should be better than rendering a blank page." :-) Best regards, Simon
|
|
Rank: Advanced Member
Groups: Member
Joined: 5/14/2013
Posts: 45
|
One additional comment: A good option would be to have a FallbackWidth in configuration.
Assume something like:
options.AutoFitX = ScaleToFit
options.AutoFitXFallbackWidth = 1200
Then when unable to determine the width of the page it would use the Fallback value as Screen width in pixels instead for rendering.
This would have two advantages:
- Also in case width cannot be determined one has still an option to influence how the page is scaled (i.e. configuration instead of changing pages)
- It is a clear indication for the user of the library, that Width will not always be determinable (i.e. documentation by configuration)
Best regards,
Simon
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Hi,
We have posted a new build that will "at least render something". Please see your private message for the download location.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 5/14/2013
Posts: 45
|
Hi,
the new version indeed "renders something". It looks now identically to AutoFitX = None.
This is definitely better than nothing, but as half of the content is missing the solution is of course not very satisfying.
Is something like the AutoFitXFallbackWidth a possible option for you?
Thx and best regards,
Simon
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Hi,
When AutoFitX is none, the output width are determined by HtmlToPdf.Options.OutputArea and HtmlToPdfOptions.ZoomLevel. So you can use those property to adjust output window width.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 5/14/2013
Posts: 45
|
Sorry for bothering again, but thus this mean, that if AutoFitX is set to ScaleToFit and ZoomLevel is set, then
1. It will first try to ScaleToFit
2. And it will only use ZoomLevel if this does not work.
Stated differently: AutoFitX has priority over the ZoomLevel setting?
Thx and best regards,
Simon
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
Hi,
No. ZoomLevel is applied before scaling. So for example, the default paper width is 468 ((8.5 inch - 2 inch margins) * 72 dpi). So if you do not set zoom level (default to 1), then the window width will be 468 pixels. Most page won't fit into this width. So when the converter loads the page, it sees the page is wider (for example, 800 pixels), then it will automatically apply a zoom level (for ShrinkToFit mode) of 468 / 800 so that the full page fit on the paper.
If you set ZoomLevel to 0.5 and load the same page, then the window width became 468 / 0.5 = 936. In this case if it loads a page that is 800 pixels, then it won't automatically scale it down. Thus for ShrinkToFit, you will see the page not filling the whole paper. In ScaleToFit mode, it will automatically adjust the 0.5 value to 468 / 800 so that it still fits the page.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 5/14/2013
Posts: 45
|
Ok, we implemented a fallback now using the Zoom option. That's closed then too for us.
Thx and best regards,
Simon
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,080
|
You are very welcome. Please feel free to let us know if there is anything else.
Thanks!
|
|