I created a simple report and uploaded it to my report server. It looks correct on the report server, but when I set up an email subscription, the report is much narrower than it is supposed to be.
Here is what the report looks like in the designer. It looks similar when I view it on the report server: [http://img58.imageshack.us/img58/4893/designqj3.png]
Here is what the email looks like: [http://img58.imageshack.us/img58/9297/emailmy8.png]
Does anyone know why this is happening?
This issue is fixed in SQL Server 2005 SP3 (it is part of cumulitive update package build 3161)
Problem issue described below.
http://support.microsoft.com/kb/935399
Basically Full Outlook 2007 Client Uses MS Word HTML Rendering Engine (Which Makes Web Archive Report Looked Jacked Up).
NOTE: Web Outlook 2007 Client Uses IE HTML Rendering Engine (Which makes Web Archive Report Look Okay).
We have installed the patch on DB housing Reporting Services and it does fix the issue. Emails look all nice and fancy now.
I notice that the screenshots show Outlook 2007. Perhaps you're not aware that Microsoft somewhat hobbled the HTML capabilities of Outlook in 2007, and now it uses the Word HTML engine, and not the more advanced Internet Explorer one? Might this explain the lacklustre appearance?
http://www.sitepoint.com/blogs/2007/01/10/microsoft-breaks-html-email-rendering-in-outlook/
I got around this problem by doing the
following:
Add a Page Header to the report
Add a line to the page header. Set the width of the line to the
desired page width.
Set the line colour to white (eg to hide the line)
Hope this helps someone else,
Following on from girlC0d3r's solution, images aren't always guaranteed to be shown in an email.
A better solution to widening the report to prevent the content from wrapping is to have a long unbroken string of characters with no whitespace.
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
By giving the text the same color as the background of the email (e.g. white) they'll widen the report and be invisible to the user.
I don't see anything but my first guess is that the fonts are vastly different. The designer has one font and the email is a flat, no-frills kind of thing with a simple font. Without concrete examples, this is just a guess.
I don't think it's a font thing, because the text is being wrapped a lot, and it looks about the same size.
The images show in my preview, but not in the final post. So, here are links to them.
Report in the designer: [http://img58.imageshack.us/img58/4893/designqj3.png]
Email result: [http://img58.imageshack.us/img58/9297/emailmy8.png]
What report output format did you specify for the scheduled job? It seems to me you used HTML, which will autoscale depending on the output browser (HTML adapts).
If having the same layout is important then use PDF as the output format. Then, if the user wants to print the report you know exactly what it will look like and that it will fit nicely on the page.
Can you try a different format? pdf or xls maybe. In my experience web archive looks goofy. Don't know why.
Yeah, I'm using HTML. I would prefer to stick with that, because the users can just read it in their mail clients. PDF or XLS would require them to open an attachment.
I know that the HTML resizes itself to fit the browser, and that's a good thing. The problem I would like to fix is the wasted space - in the email client, the HTML shrinks too much.
I got around this problem by doing the following:
Add a Page Header to the report
Add a line to the page header. Set the width of the line to the desired page width.
Set the line colour to white (eg to hide the line)
Hope this helps someone else,
girlC0d3r is along the right lines (no pun intended), but the line will likely be shrunk along with the rest of the HTML in the email. A workaround I used yesterday was to create an image 1px high by 600px wide (or whatever), the same color as the background, and bring it into the report as an embedded image. Place it above or below the body of your report. This should force the intended width in the final email. I used this technique successfully in a report yesterday.
I just ran into this issue myself, exactly as portrayed in the OP's screenshots. The reports were beautifully rendered in nearly every format except for Web Archive. My trouble was the use of a rectangle containing each matrix that did not span the width of the report. Upon stretching it out through the remaining white space, the condensing behavior ceased. Hope that helps someone who doesn't have quick access to an SP upgrade!
Where it is not an issue of running on old software that needs a patch...
The reason is the columns are different sizes is because the MHTML Device Information Settings, 'OutlookCompat' is set to true
When creating an email subscription with MHTML format and open the report in Outlook, A forum post by Microsoft employee Fanny Liu says
change the OutlookCompat configuration setting for the MHTML Rendering extension in rsreportserver.config. Set the value to: False.
As I was researching it appeared that this would impact more than just column size. In my instance it was not that big of deal so I decided to leave well enough alone. It is correct in PDF and web, the email I send includes a link back to the report, if the client wants a pretty report they are going to want it in PDF, the email format is not expected to be printable.
Encountered the same issue and this worked for me.
Go to --> Properties --> Report
Set InteractiveSize Width to 4.9in
Set Margins to 0 for Left, Right, Top, and Bottom
Set pageSize to Width to 4.9in
Related
I am generating various invoices, shipping manifests and similar documents via QRPs from an ERP program written in TD 4.1.
When my customer just prints these regularly from the program to a normal printer, they come out fine.
The customer also prints them to PDF via FreePDF XP, this happens from the printing dialogue (FreePDF XP being selected as a printer).
This results in part of the right side and the footer being cut off.
Format-wise, the reports are using Paper Style A4, page margins are top=0.8, bottom=0.85, left=0.95, right=1.0. The PDF printer is also set to A4, but has no margin settings available.
I'm grasping for straws here, but is there any way I can make this work from within the report or possibly programmatically, or is this purely on the printer driver side?
Oh, decreasing the width/height is not an option for these documents, sadly.
Pity you don't use a newer version. With TD5 and newer you can create PDFs with the integrated Report Builder, so you don't need any 3rd party tool.
Couple of ideas:
SalReportPrintToFile() and eMail the file.
SalPrtSetParmNum( PRT_nMarginTop, nMargin) ( i.e. adjust the margins via TD app for PDF's )
Have a separate .qrp for PDF's with the larger margins already preset in the qrp.
Is it possible to try the output on another pdf printer as well ? If possible try the output on another pdfprinters like PDF24Creator also.
If available in version version 4.1, have a look on SalReportSetPrinterSettings( ) function and its parameters.
bOk = SalReportSetPrinterSettings (hWndReport, strPrinterName, nOrientation, nPaperType, nWidth, nHeight)
SalReportSetPrinterSettings function sets the printer properties at runtime. The function can be called from the message action of SAM_ReportStart message.
Passing an invalid value in a parameter causes that parameter to be ignored, and the default setting will be used instead.
3.If feasible can try third party paid tools like BullZipPDFPrinter.apt that you can be intagrate with TD.
As you can see on the below image everything looks fine on PDF but on Web Viewer/Preview the numbers are not aligned nicely.
I don't understand this ... what can I do to display the numbers like in PDF form? FYI this is a column of a row of a table and the content is a 1x2 Grid, has two data elements one in 1st column other in 2nd column. Both data elements are right aligned. I tried to fix this problem with padding the first element 30 from left but didn't help. I would be glad for your tips!
The Previewer tends to offer less then optimally formated or fully functional design. Open the report in the format/tool that will be used in the final delivery for true testing durring design. Personally I have Apache on my test server and do all of my preview testing as a web page.
Edit based on comments
I don't recall ever seeing anything like this occur. If you create a new report using the sample data base, do you get the same issue? If no, then you have something off on this report, it might be easier to create a fresh report, without the issue. If yes can post your report with example data at http://developer.actuate.com/community/forum/index.php?/forum/2-designing-birt-reports/ so others can see if they see the same issue.
For some reason my subscription to a report gets emailed using the subscription service, the font sizes are increased only on text that has an underlying link for example:
However, when I run the report normally (just navigate to it using the browser), all is fine:
What am I doing wrong??
Me too. There is no fix
I just get mine either via pdf, excel or html not mhtml.
But html has it's own issues and is not recomended.
I have a RDLC report and I am displaying it on the Report Viewer Control in my front end application. I get the report perfectly and theres no problem in it.
But the problem arises when I try to export the report to a PDF (using available option - basically the inbuilt option).
I get the report in 3 pages whereas my client wants it to be in a single page. I am not able to figure out the reason for it as in my report viewer I see only one page but in a PDF there are 3 pages. I have only four columns with no data, still they are breaking up into multiple pages. 2 columns on 1st page 2 on second page. Not real sure what happened to the 3rd page. Somebody recommended changing the paper size of the default printer but I didn't think is was worth trying.
Can something be done abt it so that I can control the size of the report???
This can be a real PITA but there are several things you can do to get you there in BIDS.
To see what it will look like as a pdf use the "Print Layout" button on the preview mode toolbar.
Goto the report properties and set the orientation and paper size as you need them.
Remember the margins in the report properties to make your report display area smaller. I generally set these smaller than the defaults.
Go back to you report items and make sure they are smaller than (pagesize - margins)
This should help.
you can try setting InteractiveHeight=0 , I know that at least works for the MHTML output, not sure about PDF, but it might lead you in the right direction
I'm working on my first significant Sql Reporting Services project and am having problems with paging. Most of the reports are already working.
What is happening is that I"m getting different numbers and locations of page breaks between Web Reportviewer, PDF and Word documents. The word is the closest, but none of the three are really correct.
I've looked for the for the obvious like extra paging and making sure the report does not go outside of the left or right margins. My problem is that I'm not sure how to go about troubleshooting reports that pages that do not break in the correct location.
Does anyone have a suggestion where to start?
I'm using VS2008, SQL2008 DE on Vista Dev box.
This isn't really a problem - the different renderers are rendering the report appropriately for their output. The web viewer is optimised for screen-based reading and generally allows more content per page than the PDF viewer does as the PDF viewer is constrained by the paper size that it formats to. Thus you get more pages when rendering for PDF than web; however, the content of the report is exactly the same.
The best illustration of this is the Excel renderer - the Excel renderer renders the entire report onto a single worksheet in most cases (for reports with grouping and page breaks set on the group footer it will render each group on its own worksheet). You wouldn't want the Excel renderer to artificially create worksheets to try to paginate your report. It does the appropriate thing which is to include all the data in one big worksheet even though that may be logically thought of as one big "page".
The web renderer page length is determined by the InteractiveHeight attribute of the report (in the InteractiveSize property in the Properties pane for the report) but the interactive height is an approximation rather than a fixed page break setting and your page breaks may still not conform to the PDF version even though the InteractiveHeight is set to the same length as your target page length.