I'm working on a Microsoft Dynamics CRM Quote with a separate header report and sub report.
The sub-report has a detail grid of what is quote, a terms and conditions statement which amounts to a large block of text, and other items.
When the report shows on screen, the Quote looks just like I intended. However, when I export to Word or PDF the long text block of terms and conditions will not print until the second page and there is a lot of white space on page 1. I set "Keep Together" on that text box to false, but that does not make a difference.
Also, I am getting blank pages in between worthwhile pages containing text and I think this is because one of my objects is too wide horizontally to print on paper.
Can anyone help me with the following questions:
What is the best way to know whether what you are authoring will spill over to more pages horizontally?
How do I set the large block of text not to begin a new page if it does not fit? I can't seem to find the setting. Is my only option to divide this large text box into many smaller boxes?
I have run into similar issues before with wide reports. One of the easiest things to fiddle with are the margins in the report itself. This can be configured in
Report > Properties > Margins
Related
I have a report in Access that is from a checklist form for closing down projects. When the report is loaded, depending on the project type, certain labels and their combo boxes are marked as not visible. This is done using VBA and the visible property of each control. I have noticed that the report still includes these combo boxes and labels as blank white space. Is there a way to remove the white space?
I have set the detail and the overall report to can grow and can shrink. I am thinking about possibly using sub-reports to do this but I am unsure if it will work.
Edit: Another solution I am thinking about is building several different reports and using an if statement for the project type to determine which report to open but this feels excessive to me. This solution would report in at least 5 separate reports.
Controls don't take space in Microsoft Access. They are positioned at a certain, predefined position, on a report of predefined size. There are little dynamic things about it (yes, nicomp is right, the CanGrow property makes it a tiny bit dynamic).
If you really want, you can move up all controls below a control you're hiding by the height of the control you're hiding, assuming controls take up the full width of the page. To do that, you can use something like the snippet below (iterate through all other controls):
If MyHiddenControl.Top < MyOtherControl.Top Then
MyOtherControl.Move MyOtherControl.Left, MyOtherControl.Top - MyHiddenControl.Height
End If
And if you want to do it properly, add margins for controls and resize the report detail section too.
If controls don't take up the full width, it's considerably more difficult to dynamically organize your report.
It seems so basic and surely resolved by SSRS 2014 SP1 but I can't find a way in Print Layout (for PDF ultimately, but this is simple display) to allow a tablix to render at the top of following pages when a text box displays above it on the first page (eg. address details which would not be wanted on every subsequent page filled by tablix results). This results in unprofessional wasted white space above the results on every page after the first.
The tablix seems "stuck" so it only starts on the page wherever you put it on the design layout (using Report Builder because SSDT not playing with VS2015, but same things should apply). That's when the text box above it naturally doesn't even display on the subsequent pages - why would it, it's done its job and is not repeateable! After all, it's not in a header.
Have set the textbox to CanShrink=true but its still holding the space (because it's content remains, fair enough).
Also tried hiding the textbox (and should be able to do this conditionally on subsequent pages) but whitespace is still there, which is odd and perhaps shows the real limitation.
Applied ConsumeContainerWhitespace=true on report level (you would have thought that would do the trick) but no joy.
Even put both textbox and tablix in a same Rectangle so they become "peers" and maybe control the whitespace better, but nope.
Would prefer the header to repeat and the textbox address to only be on the first page, but another annoying limitation is that for headers there's only a "PrintOnFirstPage" option, not one to print on first page only! Of course, a workaround for that like SSRS Report Builder - Only Show Header On First Page (With Page Numbers) is to move textbox into the body area and hide, but as noted, that still leaves the stupid whitespace on every subsequent page - d'oh!
Surely there's a way to resolve this basic requirement, or maybe I'm missing something obvious?
EDIT: Remembered I never had this problem before and realised it's now only because there are multiple Projects per Worker (sorry, not enough rep yet for pic). If I choose a parameter period with only one project, the line descriptions will continue on the top of any subsequent pages. Only if the tablix header group (Project: [TaskDesc] and Worker) changes does a new page start - but with the tablix at the original page 1 layout location (ie under the textbox), not at the top of the subsequent page where it should be. Hope this clarifies - looks like a bug, odd tablix behaviour, but maybe a workaround?
If you want a non-repeating TextBox, just make sure it's outside of a repeating report element. This means outside of a Tablix or Rectangle.
Just place the TextBox at the top of your page and place the Tablix/Rectangle below it. When the Tablix/Rectangle grows beyond the maximum page height, it will break and continue at the top of a new page.
If you simply think there is too much empty space at the top of the page, try fiddling around with the page margins.
I currently have a Matrix within an SSRS report. Usually, the matrix will fix to a standard page in portrait mode, however there are cases where the length of the columns will exceed a page. Is there a way to have SSRS render the report to a PDF where this Matrix would auto-size and shrink all of it's contents, ie: font, column widths to fit within a page? I don't want to shrink all objects in the SSRS report to fix the page, just the width of the Matrix.
If you were dealing with height, I would say that that's not a tablix configuration. The tablix would be only expanding because of the columns. And the columns would be expanding because the textboxes that are inside them expand.
So, you would need to deal with it on each textbox by Right clicking the textbox inside the column and select "text box properties". On the general tab uncheck "allow height to increase".
Strangely there isn't an option to width. This link tells about the CanGrow and CanShrink properties but I wasn't able to make it work. Maybe if you want to give it a try.
-> Go to report tab
-> Select the Report Properties
-> Select Paper Size "Letter" and "Width & Height" as per standards ("8.5 * 11" or "11*8.5")
Despite the downvote, Nawaz has the correct answer
To fit it to a specific page, especially for pdf output, then you set the size to A4. I always have three templates for this purpose, screen, pdfland and pdfport. I resize my headers, footers, titles and corporate imagery for each of these templates. It's a pain, but you can incentivise your users to ditch the pdfs and the printing and the paper by creating decent dashboards for them so they have live data to hand. That's really the only decent way I've found of getting them out of old and poor habits
So either right click outside the body of the report and select Report properties, or select it from the properties window tab at the right of the screen, then set the size to either letter or A4. It's not ideal, but if you do not limit the report size in this manner any dynamic columns will render outside the pdf and create multiple pages that need to be stuck together later
edit: If you really need to resize in a hurry, you can open the report as code, and use the replace function to reduce the size, however it is often easier to reposition the tables by hand
I have a report created in SSRS 2008 that I call from and display in an asp page using the ReportViewer Control. In the ReportViewer my report has an extra/blank page at the end, but when I export it to PDF my report is perfect!. Nothing gets off the page, margins and size are all fine, under 10.0 in for a landscape report. Any idea what could be causing this?
Short Answer: Try shrinking the vertical size of the Body so there is no whitespace below the last page item.
Long Answer: I had the opposite problem when using reportviewer to render a 1-page form letter. Reportviewer rendered it correctly (one page) in the browser, but the exported PDF added a blank page 2. The Body size in my .rdlc file was exactly 8.5 x 11 in. so I could see the margins. Shrinking the vertical size of the Body to remove the whitespace below the last item (9.8" in my case) fixed the problem. (The exported PDF still has a page size of 8.5x11.)
(Thanks jimconstable. I don't yet have the "reputation" to vote for answers.)
Is the report surface larger than the page? That will cause an extra page that might not be there in a pdf.
This is usually caused because some of your page items... text boxes, rectangles, lines, tables... fall outside of the margins. I usually work on rather complex reports and what I have to do is put boarders (with different colors) on each thing that has an edge near the right hand of the page.... then when you preview, you can tell by the colors which thing is overflowing. Then you can re-size the objects or the margins until nothing overflows and the extra page is gone.
This actually happens a lot with sub-reports. They can push over textboxes, rectangles, lines... anything... that are placed to the right of them.
This can be an incredibly frustrating problem but I highly suggest adding colored borders to your report objects until you find what is spilling over. Sometimes - it can even be the canGrow property or it can be just white space left below your lowest report object so be sure to drag the bottom of the report body almost all the way up to the lowest object on your report (sometimes if the report body touches the lowest item that item's content can be cut off though, I always leave a little space, about the height of one of these letter's I am typing)
I've been having a similar problem (though there was also a blank page in the exported .pdf for me), which I eventually solved by doing the following:
Opened up the .rdl file in my text editor of choice
Searched for <Width> / <xxxWidth> tags, and reduced all the values contained between these tags to be less than the value minus the width of the margins on each side.
For me, the problem width belonged to the top level <Report> element, and changing it didn't affect the appearance of the report.
Of course, the next thing to try would be doing the same with <Height> tags.
There is a confusion there on the page design. Developers would think the report being designed is WYSIWYG, but actually it's NOT!! Microsoft reportviewer will take your designed page as the content!! and append the margins defined on the outside of your page, and turn out that your page can never fit in to one page!!
So, when you design a new report, focus on the content area, the client area, including your headers and footers, and allow margins to be appended on your outer border.
I had the same problem with a very simple report. My solution was in the Report Properties\Margins, set all the margins (left, top, right, bottom) to zero. That shrinks the report width and height. Apparently the margins are outside of the page size, usually (8.5 x 11 in).
I hope this solve the problem.
I also got the blank page at the end of report, but it disappeared in PDF. And I found that, if we uncheck the option "Add page break after", the blank page will not appear in SSRS. But When we export to PDF, there are no page break in PDF.
I've found that removing the Column Group for a detail report solved the problem. Nothing else worked. I made sure the Body fit within the Page size, made sure there was nothing extending into a margin in the Header or Footer. I didn't need column grouping and the output was the same without it. It seems to be necessary when using the Report Designer but isn't necessarily needed for the resulting report.
You have to check that the width of the bofy in the "Body properties" tab is not higher that the width of the page in the "Report properties" tab, otherwise the last part of the body renders in another page. A4 size is 21cm x 29,7cm and make sure to consider the margins to calculate the max body size.
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.