Welcome Guest Search | Active Topics | Sign In | Register

ASPXTOPDF Control causes footer to appear on top of screen? Options
gaillimh
Posted: Tuesday, March 18, 2014 10:05:25 AM
Rank: Newbie
Groups: Member

Joined: 3/18/2014
Posts: 3
Hi.

We are trialling your product before deciding whether to purchase or not and have run into an issue on our web pages.
When we add the ASPXToPDF server controls to our eb pages - it causes the page footer to appear at the top of the screen befre the main body of the page.

Is this an issue that you have seen crop up before? The pdf generation itself does work but obviously we cannot use this approach if it causes the rendering of the page to be skewed.
Also I have noticed that when I attempt to just generate a pdf for certain sections of the page this does not work - it renders the full page.
I have used the code as per the samples (and also used the fully qualified name rather than the individual control name [ie. the MasterPage adds on some tags at the start of the control name & we are catering for that but to no avail]).

Any ideas as to what may be happening here?
Code snippet shown below...

Markup:
<%@ Register Assembly="EO.Web" Namespace="EO.Web" TagPrefix="eo" %>
<eo:ASPXToPDF ID="ASPXToPDF1" runat="server" OnBeforeRender="ASPXToPDF1_BeforeRender">
</eo:ASPXToPDF>

Code To Render The PDF
ASPXToPDF1.RenderAsPDF(fileName);

protected void ASPXToPDF1_BeforeRender(object sender, EventArgs e)
{
// we only want to render out certain parts of the page
HtmlToPdf.Options.VisibleElementIds = "MainContent_MainContent_divActivitiesList";
}
eo_support
Posted: Tuesday, March 18, 2014 10:38:08 AM
Rank: Administration
Groups: Administration

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

As for the footer, there are two things for you to check:

1. Try to use Google Chrome browser to see visit your page and see if it renders fine. Very often different browser renders the same page differently. Our rendering is most close to Google Chrome;

2. You may want to turn off the page footer when you convert to PDF. The reason is the "footer" in PDF is not the same as in a browser window. For a browser window, there are no pages and the size of the browser window is known. But this is not true for PDF. For PDF, it tries to automatically calculate the full height of your page and give you as much as you wanted, then divide the result into multiple pages. So it has no "idea" place or clear definition of where the footer should be.

We are not aware of any problem with VisibleElementIds. Using the full qualified name is correct. You can try to use divActivitiesList.ClientID instead. The only thing that you would want to be aware of is, when you set VisibleElementIds, the whole path from body to your visible element is kept visible. For example, if your HTML is like this:

Code: HTML/ASPX
<body>
    <div id="div1">
        <div id="div2">Child 1</div>
        <div id="div3">Child 2</div>
    </div>
</body>


If you set VisibleElementIds to "div2", then both "div1" and "div2" will be visible ("div3" will not be visible). This usually is not an issue but if you have certain style settings, for example, if you have paddings on "div1" then that padding will apply.

I would recommend you to try it with simple page with simple elements such as a DIV with a fixed ID and see if it works. At runtime, the converter searches the DOM tree for the element. If the search fail then it will be ignored and the whole page will be visible. There are various reason that can cause the search fail. For example, if in your server side code you have set divActivitiesList.Visible = False, then that element would not exist on the client side at all, thus would cause the search to fail. It can also fail when you have invalid HTML structure, such as unclosed HTML elements. So you can try with simple HTML to see if that works first and then add other elements block by block.

Thanks!
gaillimh
Posted: Tuesday, March 18, 2014 6:18:44 PM
Rank: Newbie
Groups: Member

Joined: 3/18/2014
Posts: 3
Thanks for the reply. I've tried it on Chrome and IE and the display is skewed in both browsers.
I created a very quick web form project and put a few divs on the default.apx page and tried only showing certain div controls and this worked fine.

The master pages that we use on our site would obviously have more going on in them than the master pages from the sample I tried above so I assume there must be something there that is conflicting with your code. As I understand it your code "intercepts" the html that is to be rendered and manipulates it in some way. This must be causing the issues with the rendering of the page as when I compare the markup (by viewing page source in chrome) it doesn't seem to look right
[eg the
<!DOCTYPE html><html><head> etc....
tags that should be at the start of the markup are moved way down the page once I add the ASPXToPDF control to the page].
I guess we may have to look for an alternative approach.
Thanks for your post

I assume
eo_support
Posted: Tuesday, March 18, 2014 8:14:30 PM
Rank: Administration
Groups: Administration

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

We don't manipulate the HTML at all. We have a built-in in browser engine based on WebKit. That browser engine loads and render your HTML the same as a "normal" browser does. The difference is instead of rendering the result to the screen like a "normal" browser does, "our browser" renders the result into a PDF file. So if a page is skewed in your browser, it's almost certain that it won't render right in "our browser". As such you need to fix your page in your browser first. Since our "browser" is based on WebKit which is the same rendering engine Google Chrome uses, we usually recommend our user to verify their page with Chrome browser.

Thanks!
gaillimh
Posted: Wednesday, March 19, 2014 4:37:43 AM
Rank: Newbie
Groups: Member

Joined: 3/18/2014
Posts: 3
Thanks again for the swift reply.
Maybe I'm misunderstanding how the whole process works.
The issue we are having really is not with the rendering of the pdf (aside from the visible elements list not working as expected it does render the page to pdf).

Our issue really is that by adding the aspxtopdf control to our aspx page - when we navigate to that page the page displays with the footer at the top of the screen (when we navigate to the screen I mean not in the PDF).
The only difference between the page that renders correctly and the page that renders slightly off is the addition of the aspxtopdf control to the aspx page.
When we navigate to the page and view the source it looks strange so I assume the markup must be modified in some way?
Is there any way to stop this from occurring?
eo_support
Posted: Wednesday, March 19, 2014 12:24:41 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,196
Ah I see. This makes sense. ASPXToPDF works by intercepting the output of your page and then call HtmlToPdf.ConvertHtml to convert the result HTML to PDF. The interception mechanism only works for the "normal" page rendering process. So please check your page whether you have some special logic about the output (for example, instead of letting the control to render itself, you call Response.Write to render the result). Likewise, if you have other similar module that modifies/intercept the output (such as setting Response.Filter) in your code, then it may not work correctly as well. I would suggest you to try to comment code out block by block in your page to see if you can find the offending part. You would also want to examine your web.config to see if you have any other modules. You can temporarily comment those out to see if you can identify what triggered the problem. Once you find out the trigger, we can then go from there.

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.