I am creating a pdf report using ods pdf . The ods pdf contains many proc report procedures generating their corresponding output reports.I want one of the proc reports output in a single pdf page. But the report is so big that it occupies two pages. How can I set the report in a single page? At the same time I dont want to alter the alignment of other reports.
You don't mention the reason for the report occupying two pages. Is it because there are too many columns or too many rows. The reason will affect the solution.
It would be helpful if you provided the report size in columns and rows.
ODS PDF calculates the place to insert a page break based on the orientation of the output file, the margins of the output file, the font size used for the output and the cellpadding in each cell of the table. So the only way I know of to get more rows on a page are to change those options.
The program below shows how to specify options to change PROC REPORT output so that 63 row and 8 columns fit on one page of a PDF report. PROC PRINT options would be similar. PROC TABULATE options would be specified on a TABLE statement or you could have to make a custom style template. However, 8pt is small and so you might not want to apply that font size to all output except where "fit" is important.
** make some data with 63 rows and 8 variables;
yyy = 'yyyyyyyy';
zzz = 'zzzzzzzz';
do xxx = 1 to 3;
if _n_ le 6 then output;
Once the results come back to the browser, it is the browser interface with the printer that controls page breaking when the output is printed. Some SAS style templates do have a style attribute called 'PageBreakLine' that contains a CSS instruction (page-break-after:always), as shown in the <P> tag below for BYLINE Region=Canada:
<p style="page-break-after: always;"> </p><hr size="3">
<div class="c Byline">Region=Canada</div>
When you create HTML output, if your stored process uses a style template with this instruction -and- your browser respects this CSS instruction, the browser will send a page-break to the printer for the HTML output.
1) you may get different behavior by simply using a different style template with your stored process. I believe that the SEASIDE and the NORMAL styles do not utilize this page-break-after:always instruction.
However, changing the style template for stored processes, might require changes in multiple places. For example, if you were changing the style template for use in the Information Delivery Portal or Web Report Studio, then you might need to alter the CSS definitions stored in the middle tier XML configurations. If you were changing the style using the Style Wizard in Enterprise Guide, then you would need to change a CSS file and not a style template.
3) switch to PDF output -- which should be viewable in a browser, but also printable using the internal PDF page breaks (you can use STARTPAGE=NO with ODS PDF to put multiple BY groups on the same page). For your stored process, if you were going to generate PDF output, then you might also need to change the stored process header information (STPSRV_HEADER) so that the browser launches the correct helper program to open the PDF file.
As I explained, the page-break-after:always is coming from CSS generated by the style template -- that's why you are still getting the HR and the CSS property. I'm guessing that according to the rules of the cascade resolution the the internal STYLE= attribute in the HTML must be overrriding what you have for your .Body class and Body and P classes. ODS is not putting the page-break-after:always into anyplace except the one HTML tag that I showed above.
Since the style template in use for your stored process is translated to CSS in-line <STYLE> section -- at the time the SP is run -- I really think the ONLY way to have an impact is to alter the style template or switch to PDF or switch to a STYLE like SEASIDE, NORMAL or MEADOW which do not use the HR or the page-break-after:always CSS instruction.
PS...OPTIONS NOBYLINE does not impact the <HR> that's put into the file being created with HTML tags -- so the HR is coming because each BY group is generating a separate TABLE and, in a paged destination, each TABLE would start a new page. Since ODS HTML is not a "paged" destination, the <HR> tag is showing you where the "logical" page is located. The HR tag, as I explained is part of the PageBreakLine style attribute that is defined in the style template.
** changed to explain why NOBYLINE had no impact on the HR tag.
I often set the papersize to tabloid (11 x 17) to give me the needed real estate. When printed to letter (for those who do), the printer usually takes care of resizing to letter size. Legibility is still ok too.
Not with a stored process that returns results to a browser. Did you try changing the style template or CSS -- also assumes that you put the template or CSS files in the right place on the Platform servers???
If you didn't or don't want to go further down the CSS or style template road, PDF results returned to the browser give you the most page break suppression control -- since you can use STARTPAGE=NO option with PDF and since most browsers can receive PDF results, this should resolve your issue.
If you are having problems switching your stored process to PDF or you want to continue looking for an HTML-based solution, then you might work with Tech Support -- they have the BI Platform and stored process expertise to look at everything you've got and make recommendations.