There are 19 variables in one dataset and for that dataset if I create a pdf file through ods odf then it shows 8 columns in first page and remaining 11 columns in second page and third pages,but i want all 19 columns should come in first page only.Is there any way to do that.
Your width= option is essentially ignored by PROC REPORT when you are using ODS PDF, ODS RTF or ODS HTML destinations. If you want to reduce the width of the LDESC column, you would need to use the CELLWIDTH attribute in a STYLE= option.
ods pdf file='c:\temp\descript.pdf';
proc report data=sashelp.asscmgr nowd;
ods pdf close;
If I use style=journal or font_size=4pt then I am getting all the columns in first page itself but the problem is I should report in default style only and if I use font_size=4pt then the data is not visible.
Yes, there are always tradeoffs. If you remove the journal style option from the code, you will then generate output using the default style for RTF or PDF. I suspect that 4pt might still work for you to show all the columns. You could also change cellpadding to 1px instead of the 2px that I have in the code.
Paper is paper. 8 1/2 by 11 or 8 1/2 by 14. PDF thinks that it is limited to a PAPER size. And, reasonably so, because if you want to PRINT, then you have to PRINT on something -- presumably paper. Otherwise, PDF files, when viewed with Acrobat Reader can be zoomed so they are readable on the screen.
At a font size of 4pt, readability on paper goes out the window, while readability on the screen is still possible. That's your tradeoff.
If readability on the screen is of paramount importance, then I suggest that you switch to ODS HTML for on-screen viewing but use the PRINTER style ods html file='wombat.html' style=printer; this gives you a screen view that is as wide as it needs to be, but uses the PRINTER style -- which is what the PDF destination uses.
If, on the other hand, readability on PAPER, when the file is printed, is of paramount importance, then you must live within the physical limitations of dealing with PAPER and PRINTER-based destinations. This may mean that you have one form of the report for on-screen viewing and another form of the report, perhaps with fewer columns or with a different structure, for printing.
This may be a good time to reexamine whether ALL the variables are needed or whether they might be able to be presented in a different form. For example, if you had 3 variables, name, street and city, rather than present them in 3 report columns, one for each variable, I might be tempted to make them 1 "temp" variable and put a line feed (using ODS ESCAPECHAR) between them, so they would essentially "stack" in one column. Here's that concept illustrated with 3 variables from SASHELP.CLASS:
length onecol $50;
onecol = catt(name,'#n Age=',put(age,2.0),'#n Height=',put(height,5.1));
ods pdf file='stackit.pdf';
proc print data=class noobs label split='/';
var onecol sex;
label onecol = 'Name/Age/Height'
sex = 'Gender';
ods pdf close;
In this program the ODS ESCAPECHAR used is a #. That means the special string to insert a LINE FEED or CARRIAGE RETURN into a variable is the #n string (as shown in the CATT function).
Another option is to build a TABLE template that stacks the columns automatically (so you don't have to concatenate them). The only limitation here is that you can't stack a numeric variable with a character variable...I believe that you can only stack items of the same type in a TABLE template.
It is entirely possible that Tech Support could look at your data and your current report program and make some other recommendations. However, I do not think you will actually be able to have one report that is viewable on the screen and printable at the same time. I suspect that you will have to make 2 versions of the report -- each one designed for the particular medium (screen/paper).