SSRS reports pdf version having printing issues - reporting-services

We have been trying to export SSRS reports into pdfs and trying to print them.
The pdf on printing prints smaller sizes of the fonts.
The digital version looks right. We have used custom sizes on some of the reports and some use A4.
But this problem occurs on both. Are there any compatibility issues that we need to verify or any config changes. Pls suggest.
Any ideas would be very helpful.

Check your margins and report width.
The report Body width + the margins must be equal to or less than the Paper Size width.
You may be going over the margins for your printer and your PDF reader is scaling it to fit on a page.
You can check by looking at the PRINT options and making sure that it doesn't Shrink Oversized pages or Fit to page. Mine has an Actual Size setting.

Tried this. But we still do have issues printing some of the reports. Right now we are tweaking the margins and the fonts to make sure each report prints fine.
We wanted to know if there is any other way to achieve this.

Related

SSRS report not having the same font formatting on PREVIEW and PRINT

Had this issue when working with report viewer - now having the same issue with SSRS. Basically what happens is I create a report with a certain font - it looks perfect in the preview mode - however, when I go to print it - it makes the text look different - kind of squeezed and looks to be complete different font as a matter of fact. Included image with what it looks like in PREVIEW and PRINT.
Anyone had an issue like this before?
Thank you.
This page and many similar ones give information about rendering, but none of them seem to answer the questions "does this text fit in this box?" and "How big will this box be?" Rendering to IE, Chrome, Safari, Word, and PDF was an exercise in frustration and compromise, especially considering that Visual Studio and Report Builder were also different. In all cases, the height and width of the text boxes changed, the font size changed, and the spacing around the text changed.
Our technique was to prioritize the various output formats, then find settings that produced the best output based on those priorities. Given this, users see better (but still not quite perfect) results than we see in Visual Studio.

RapidMiner reporting chart not fitting

Hi I am relaive new to RapidMiner,
I am trying to get a good looking report working, using the reporting extension.
When I display a histogram chart, with the standard width and height (800x600) the bottom part is cut off. See Example
If I manually change it to 800x800 the chart is displayed correctly.
The problem is that the chart will changed, based on the input, so I would manually have to check if it fits.
Is there any way to scale the chart to fit the given space e.g. 800x600?
Edit2: This is how the Report operator and the Generate Report operator are set up:
I notice that the page settings in Generate Report are for portrait mode whilst the settings in the Report operator are for landscape. If you change image width to 600 and image height to 800 in the Report operator, I suspect this might resolve the issue for you.
It is confusing however, I noticed that Generate Report ignores changes to the page size settings - this is likely to be a bug. It's also confusing that increasing the image dimensions shrinks the rendered image. I'm afraid it's trial and error. I don't think the image will change between runs, the size is fixed by the dimensions you give it.

SSRS -> Report header changes after uploading to the server.....How can this be fixed?

I have created my SSRS report in VS2010 and it looks really good. Upon placing this on the report server the size of the header increases (twofold) and really messes up my styling.
I have tried setting the property to false. This did not work at all. I have researched all over the web and haven't been able to find a solution to this.
Any ideas?
***Update -> I removed interactive sorting from the header just to see if this was causing the increase in height, it was the culprit. The size was corrected once I removed interactive sorting. Problem being, I need interactive sorting. Also, upon removing the interactive sorting functionality, I could no longer see the text for the headers. So, I now have a correctly sized header with no text and no sorting.
Added in a height for each cell manually and changed the line height. This fixed this.

SSRS PDF export errors

I have an SSRS 2005 report, the report has two groups and one nested table inside of a group, the report is displayed correctly in VS as two pages, but when trying to export it to PDF I get 17 pages and the only correct pages I get are at the end of the PDF file.
Check the grid vs the Page Size.
If you Page Size is set to 8.5" x 11 and you have 1" margins and your Grid (The "white" part of the report) goes beyond the margins, you will get overflow on to other pages.
If you look at the picture below, you can see the grid goes just beyond the 7" mark. My interactive snf Page Sizes are set to 8.5 x 11. This exports fine. A good way to check is to switch to "Print Layout" mode. You can do this by clicking on the little icon that looks like a white piece of paper on a green background just to the right of the Printer Icon. When you view it this way, you get a pretty good idea of how it will be exported.
I have run into this problem before, generally a Table or Rectangle control will inadvertently push to the edge of the Grid and in turn increase the size of the Grid beyond your paper size and margins.
Yes, but it's been a (long) while since I worked with SSRS. I remember having adjusted rsreportserver.config
This link should help:
Customizing rendering extensions
The link is just the result of quick googling. Didn't read it through.
I had to adjust values for i.e. border width and so on, which are by default somehow a mess. And if that doesn't help, you have to adjust your report.

Any workaround for printing repeating backgrounds?

We have an HTML page which displays a bunch of pretty bars using divs and repeating backgrounds. We are in the process of making a report out of this that can be printed nicely, but this may take some time because we don't have a reporting framework in place. As an interm solution we'd like to make the HTML version printable. The background of the divs are the only problem, and they don't print because of the default setting (which can't be enabled because the workstations are locked down).
I have found a work around for printing background images, but this doesn't work when the background needs to be repeated.
Are there any other work arounds which might be able to help? I have also been trying to insert an image inside the dive and stretch it, but this is throwing off all the other relative positions and is proving to be very difficult to fix. I am still looking into this however.
I have used this ActiveX Component in situations where controlling the printer output was absolutely neccessary (think printing stickers etc).
The function you'd want is : printBackground
However this doesn't come with their free license but perhaps the cost of that license outweigh the other work arounds implementation time.
Drawback: IE only.
If you can educate your users, there is an option in the print dialog box of IE and Firefox that is labeled something like 'Include Background Images' or 'Print Background Images'
This will include repeating background images.
I couldn't load the link, and I may not be understanding the problem correctly, but...
This is more of a work-around than a solution, but would you be able to make a single image that just appears to be repeated? Or at least, is repeated (for variable browser and screen sizes), but is large enough to be 'proper' for printing (which is a much more standard size)?
The easiest way I can think of achieving this is to have different stylesheet for printing that uses standardised images that fit the containers printed on paper.
The display stylesheet would continue to use the repeated images which wouldn't hinder performance as the full images loaded in the print stylesheet would only be loaded when the page is sent to the printer.
...at least, that's what the HTML spec says should happen. Whether this is actually the case, I can't be 100% sure.