BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
xxformat_com
Barite | Level 11

Hi,

Here are three examples. Two work as expected in a PDF destination but not the third one (column width for the line statement) Do you think the output is as expected or a bug?

 

1/ In this example, everything is as expected.

 

ods pdf file="&test./reporting/test1.pdf";

proc report data=sashelp.class style(column)=[cellwidth=2cm]; 
    column name--weight; 
    define name--weight   / display; 
    
    compute before;
        line 'Test ';
    endcomp; 
run;

ods pdf close;

2/ But here, one has to use the linecontent class for the output to look ok in a PDF; it is fine in a HTML destination.

 

proc template;
    define style styles.xxtest;
        parent = styles.pearl;
        class data 
            / outputwidth         = 2cm;
            
        *class linecontent 
            / outputwidth         = 10cm;
            
    end;
run;
                       
*--------------------------------------------------------------------------------;
                                              
ods pdf file="&test./reporting/test2.pdf" style=xxtest;

proc report data=sashelp.class; 
    column name--weight; 
    define name--weight   / display; 
    
    compute before;
        line 'Test ';
    endcomp; 
run;

ods pdf close;

3/ The alternative with class header works properly.

 

proc template;
    define style styles.xxtest;
        parent = styles.pearl;
   
        class header 
            / outputwidth         = 2cm;
    end;
run;
                       
*--------------------------------------------------------------------------------;
                                              
ods pdf file="&test/reporting/test3.pdf" style=xxtest;

proc report data=sashelp.class; 
    column name--weight; 
    define name--weight   / display; 
    
    compute before;
        line 'Test ';
    endcomp; 
run;

ods pdf close;

Unexpected output

notok.JPG

 

Expected output

ok.JPG

 

1 ACCEPTED SOLUTION

Accepted Solutions
Cynthia_sas
SAS Super FREQ

Hi:

  The behavior that you note is how I would expect all of your posted code to work. Your example #1 works because the style override for the data cells (override in PROC REPORT statement for style(column)  option) will ONLY impact the data cells generated by PROC REPORT. The LINE statement will still use the style template settings because the style override on PROC REPORT only impacts the data cells. If you had done this:

Cynthia_sas_0-1623249458235.png

 

or THIS

Cynthia_sas_4-1623251953243.png

Then your overrides would have had an impact on the LINE statement output. By default PROC REPORT will use the entire report width to write the LINE text. Note that I used colors above and not cellwidth. If you try to change CELLWIDTH in a PROC REPORT style override, using your #1 syntax you would have observed the same (undesireable) results as with the template in PDF:

Cynthia_sas_5-1623252385258.png

This illustrates my point that different destinations have different ways to render the instructions when the PROC REPORT output is bound to the default style template for the destination with the overrides applied. As you can see -- just using PROC REPORT overrides without a style template, PDF behaves differently from HTML.

 

  I find it very problematic to try to "overcontrol" the cellwidth in PDF. You should not need to worry about the cellwidth of LINE statements because PROC REPORT, by default, will make the LINE text span the entire table. Overcontrolling the LINE width doesn't work, as you can see using the simplest example. Adding a style template change into the mix only makes things more complicated.

 

  Your #2 did NOT work in a STYLE template with PDF for 2 reasons: 1) because the LINECONTENT in the style template inherits from the DATA element and 2) not every destination uses style specifications in the same way. So by switching to using a template, and NOT using style overrides in the REPORT syntax, your output was bound by the way inheritance works as shown below:

Cynthia_sas_1-1623250734822.png

However, your XXTEST template inherited from PEARL style as the parent; PEARL style inherits from PRINTER style; PRINTER style inherits from DEFAULT; and DEFAULT inherits from the Base.Template.Style. But as you noted, the SAME template is used differently by different destinations: PDF did one thing with the template specification and HTML (and RTF) rendered differently:

Cynthia_sas_2-1623250897619.png

HTML and RTF continue allow PROC REPORT to control the spanning of the LINE results, but PDF allowed the template to set the cellwidth and since LINECONTENT inherits from the DATA width that you provded in the new template.

 

But with your #3 example, your style template change was to the HEADER element --but LINECONTENT does NOT inherit from the HEADER element, it inherits from the DATA element. So #3 example allowed the headers in PROC REPORT to change (which had the side effect of impacting the data cells) and also allowed PROC REPORT to use the default behavior of having the LINE text span the entire table. So, the LINE text was unaffected by the change to the HEADERs in the new template.

Cynthia_sas_3-1623251448752.png

 

  The HTML and RTF output for example #3 was the same as the output shown in #2, so it was not included in the screen shot.

 

  My best practice is NOT to tamper with the width of the LINE in PROC REPORT, especially if my desired destination is PDF. I also don't try to "overcontrol" the cellwidths in PDF. PDF destination has some complex algorithms to use fontsize and cellpadding and cellspacing to "draw" the table in PDF format and I find that overcontrolling the cellwidths can sometimes have undesirable results.

 

  Note that in my examples I created different template names and different output names so that I could keep the templates and the output together. I find it easier to test multiple template changes by keeping the names of the templates and the names of the output similar. When I've finished testing, that's when I settle on the final template name and generate the production template code. However, most of time with PROC REPORT, I find it much easier to use style overrides within the PROC REPORT syntax instead of trying to use a STYLE template with PROC REPORT>

 

  This paper https://support.sas.com/resources/papers/proceedings10/033-2010.pdf explains a little more about how inheritance works. It's a bit old because it was written for SAS 9.2, when the template syntax changed for style templates, but much of the information is still good.

 

Cynthia

 

View solution in original post

2 REPLIES 2
Cynthia_sas
SAS Super FREQ

Hi:

  The behavior that you note is how I would expect all of your posted code to work. Your example #1 works because the style override for the data cells (override in PROC REPORT statement for style(column)  option) will ONLY impact the data cells generated by PROC REPORT. The LINE statement will still use the style template settings because the style override on PROC REPORT only impacts the data cells. If you had done this:

Cynthia_sas_0-1623249458235.png

 

or THIS

Cynthia_sas_4-1623251953243.png

Then your overrides would have had an impact on the LINE statement output. By default PROC REPORT will use the entire report width to write the LINE text. Note that I used colors above and not cellwidth. If you try to change CELLWIDTH in a PROC REPORT style override, using your #1 syntax you would have observed the same (undesireable) results as with the template in PDF:

Cynthia_sas_5-1623252385258.png

This illustrates my point that different destinations have different ways to render the instructions when the PROC REPORT output is bound to the default style template for the destination with the overrides applied. As you can see -- just using PROC REPORT overrides without a style template, PDF behaves differently from HTML.

 

  I find it very problematic to try to "overcontrol" the cellwidth in PDF. You should not need to worry about the cellwidth of LINE statements because PROC REPORT, by default, will make the LINE text span the entire table. Overcontrolling the LINE width doesn't work, as you can see using the simplest example. Adding a style template change into the mix only makes things more complicated.

 

  Your #2 did NOT work in a STYLE template with PDF for 2 reasons: 1) because the LINECONTENT in the style template inherits from the DATA element and 2) not every destination uses style specifications in the same way. So by switching to using a template, and NOT using style overrides in the REPORT syntax, your output was bound by the way inheritance works as shown below:

Cynthia_sas_1-1623250734822.png

However, your XXTEST template inherited from PEARL style as the parent; PEARL style inherits from PRINTER style; PRINTER style inherits from DEFAULT; and DEFAULT inherits from the Base.Template.Style. But as you noted, the SAME template is used differently by different destinations: PDF did one thing with the template specification and HTML (and RTF) rendered differently:

Cynthia_sas_2-1623250897619.png

HTML and RTF continue allow PROC REPORT to control the spanning of the LINE results, but PDF allowed the template to set the cellwidth and since LINECONTENT inherits from the DATA width that you provded in the new template.

 

But with your #3 example, your style template change was to the HEADER element --but LINECONTENT does NOT inherit from the HEADER element, it inherits from the DATA element. So #3 example allowed the headers in PROC REPORT to change (which had the side effect of impacting the data cells) and also allowed PROC REPORT to use the default behavior of having the LINE text span the entire table. So, the LINE text was unaffected by the change to the HEADERs in the new template.

Cynthia_sas_3-1623251448752.png

 

  The HTML and RTF output for example #3 was the same as the output shown in #2, so it was not included in the screen shot.

 

  My best practice is NOT to tamper with the width of the LINE in PROC REPORT, especially if my desired destination is PDF. I also don't try to "overcontrol" the cellwidths in PDF. PDF destination has some complex algorithms to use fontsize and cellpadding and cellspacing to "draw" the table in PDF format and I find that overcontrolling the cellwidths can sometimes have undesirable results.

 

  Note that in my examples I created different template names and different output names so that I could keep the templates and the output together. I find it easier to test multiple template changes by keeping the names of the templates and the names of the output similar. When I've finished testing, that's when I settle on the final template name and generate the production template code. However, most of time with PROC REPORT, I find it much easier to use style overrides within the PROC REPORT syntax instead of trying to use a STYLE template with PROC REPORT>

 

  This paper https://support.sas.com/resources/papers/proceedings10/033-2010.pdf explains a little more about how inheritance works. It's a bit old because it was written for SAS 9.2, when the template syntax changed for style templates, but much of the information is still good.

 

Cynthia

 

xxformat_com
Barite | Level 11

Thank you Cynthia for the time and effort writing such a detailed answer.

sas-innovate-2024.png

Available on demand!

Missed SAS Innovate Las Vegas? Watch all the action for free! View the keynotes, general sessions and 22 breakouts on demand.

 

Register now!

How to Concatenate Values

Learn how use the CAT functions in SAS to join values from multiple variables into a single value.

Find more tutorials on the SAS Users YouTube channel.

Click image to register for webinarClick image to register for webinar

Classroom Training Available!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 2 replies
  • 1316 views
  • 0 likes
  • 2 in conversation