Showing posts with label experiencing. Show all posts
Showing posts with label experiencing. Show all posts

Wednesday, March 28, 2012

PDF Rendering with web form

I'm experiencing a problem with a webform which receives a binary steam back
and display it as a PDF.
The problem that is experienced is when the report reads parameters from the
querystring passed to the webform. The parameters passed to the page will
then be passed to the Reporting Services web service. The page attempts to
open the PDF, but when Adobe Acrobat Reader opens, an error appears: "Adobe
Reader could not open 'paXXXXXX.fdf' because it is either not a supported
file type or because the file has been corrupted (for example, it was sent as
an email attachment and wasn't correctly decoded)."
This problem only happens when exporting to the PDF format and runs fine in
all other formats. This error only occurs when the report is run in version
6 of Acrobat. In version 7 it is not a problem. The instance of Reporting
Services used has SP1 installed.I had a similar problem. It turned out that the web form was adding its HTML
to the end of the PDF file. Apparently Excel didn't care but Acrobat V6 did.
I fixed it by overriding the page's Render method and only called
MyBase.Render(output) when the mime type was HTML. This prevented the page's
HTML being rendered and stuck on the end of the PDF or any other non-html
stream.
Hope that helps.
Grahame
"Aidan" wrote:
> I'm experiencing a problem with a webform which receives a binary steam back
> and display it as a PDF.
> The problem that is experienced is when the report reads parameters from the
> querystring passed to the webform. The parameters passed to the page will
> then be passed to the Reporting Services web service. The page attempts to
> open the PDF, but when Adobe Acrobat Reader opens, an error appears: "Adobe
> Reader could not open 'paXXXXXX.fdf' because it is either not a supported
> file type or because the file has been corrupted (for example, it was sent as
> an email attachment and wasn't correctly decoded)."
> This problem only happens when exporting to the PDF format and runs fine in
> all other formats. This error only occurs when the report is run in version
> 6 of Acrobat. In version 7 it is not a problem. The instance of Reporting
> Services used has SP1 installed.

Monday, March 26, 2012

PDF export results in extra pages.

I am experiencing some quirks when exporting to PDF.
I have read all the other posts about page sizes, margins, etc and my situation seems to be a bit different.

PageWidth = 21cm
PageHeight = 29.7cm
Margins = 1cm

Body.Width = 19cm

I have a report that contains a bar chart (Height = 15cm, Width = 19cm) and below that a rectangle that contains two text boxes with totals information (Left = 11.6cm, Width = 7.4cm, Height 0.5cm)

Now most of the time it exports to PDF perfectly - all on one page as would be expected

If however the chart has more than say 20 items on the y-axis then the rectangle gets pushed onto an new page.

For extra information, but not to confuse the issue I also have a page header and footer that have items lined up right to the edge (left + width = 19cm) and they all display fine on the one page. It is just this rectangle that is having the problem.

When I move the rectangle to the left a bit (11.4cm) so 0.2cm away from the right hand edge then it works fine.

It is just very strange because I cant see how it is getting shifted only when the chart contains a lot of items.

Any ideas?

I finally found a solution that works for me, just after I posted - usually the way.

I have created a rectangle with left = 0cm and width = 19cm and then placed the text boxes
inside that rectangle, positioned where I need them.

Once I do that it renders onto one page.

What I think is going on here is a precision problem. I suspect that MS being a US based company their base units are the imperial system so Inches. So even though you can express your measurements in cm, pt's, etc - they are always converted to a base unit of inches. With any conversion process you can get problems with precision and that is what I think is happening here.

So I feel the best way to avoid these precision bugs is to adopt a report design strategy of not having floating report items in your report. Group items by placing them in a rectangle and set the left to 0 and the width to the exact page width boundary (in this case 19cm)

The other solution is to always use the same base units as the renderer (inches) that way you wont suffer conversion precision problems. Unfortunately for me it would take forever to convert all mine from cm to inches.