How do I set a default dimension for cell width and style element behavior in SAS 9.4

[dkratz]

Greetings,

My apologies if these have been asked elsewhere.  I did some searching and didn't see anything similar.

I am migrating a bunch of ods rtf reports I inherited from 9.3 -> 9.4, and I'm getting different output on the newer system.  Researching the issues, I can't seem to find SAS configuration changes which would resolve the issue, but I may just be missing something.

1)

I have a report that does soemthing like the following:

ods path <location which contains only a custom style specific to this report>;

ods rtf file=...  style=<previously defined custom style for the report> ... ;

proc report;

...

compute before pg;

...

etc.

Text specified in the compute block is printed using the linecontent style element.  However, the custom style specified does not contain a linecontent section, nor does it inherit from any other style.

In 9.3, the resulting text gets printed using Times New Roman, while in 9.4 it gets printed as Courier.  However I am uncertain as to why there is a difference.  Is there any way to configure ods' behavior in the case where no style has been defined for the element?  The ODS path configuration seems to rule out the implicit parent: base.template.styles

I can simply add a linecontent section to the custom style, but it would become onerous to modify the code for all the reports, so I was curious if the default can be set somehow.

2)

In a different report there's something like this:
proc report;

...

define name / "Name" display center style={just=l width=7};

...

In 9.3 the report used the width value specified without a dimension in a certain way.  Experimentation suggests that it was using it as a % .  In 9.4, it appears to be using the width value in a completely different way.  If I alter the code to include a % for all rows

define name / "Name" display center style={just=l width=7%};

etc.

I get output which resembles the 9.3 output.

Is there anyway to set the default dimension which ODS uses for width values without one specified?  Or a SAS option to force 9.3 like behavior?

I can simply modify the code manually to include the %s but, again, it would be onerous to do so across all the reports.

Regardless, pleas let me thank you for your time as well as any suggestions you might have.

[Cynthia_sas · Accepted solution]

Hi:
You can look in SASHELP.TMPLMST at the Base.Template.Style definition. This is the implied parent template for ALL style templates, starting in 9.2. If you defined a custom style template without an explicit parent, then this is the implicit parent that defines inheritance.

If you look inside the template, you will see that LineContent inherits from Data.

I do not have 9.3 to test with anymore. And, as far as I know, only Tech Support can spin up older versions of SAS to compare results. they would need your custom style template, ALL your code and some sample data. But I believe that is your best resource for a resolution.

The default unit for width should be PX (I believe it has always been PX) -- however, each destination treats that unit of measure differently. For example, in RTF, most dimension specifications are translated to TWIPS (twentieths of a printers point - -which is the RTF internal measurement). So I find it best not to "overcontrol" widths.

There is not any way to specify a default dimension for the width and it was always a bad idea to specify width without a dimension anyway. You can read about CELLWIDTH/WIDTH here:
http://support.sas.com/documentation/cdl/en/odsug/69832/HTML/default/viewer.htm#p0xi2cygmfk0wkn1ei62...


and see where it ways the default unit is PIXELS -- this has always been the default unit for WIDTH/CELLWIDTH, all the way back to V8.

cynthia

[dkratz]

Please let me thank you for your response.  It largely confirms what I had read elsewhere. 

Given the way the report looked in 9.3, I'm uncertain that the lack of a dimension was defaulting it to pixels, simply because the observed report widths don't seem to correspond to the programmed values as pixels or twips.  That's really more of a curiosity than anything else, though.

I had looked into Base.Template.Style before posting.  It's interesting to learn that it works even if you alter your ods path value to exclude SASHELP.TMPLMST (though I haven't explicitly tested that).  It seems most of the actual formatting performed by Base.Template.Style is actually specified by Styles.default?  There's a relationship between them that is still unclear to me.

Actually editing the default style values proved more troublesome, as SASHELP.TMPLMST is read only, even if you specify otherwise in the ods path.  I eventually found a hacky workaround to that.

Regardless, please let me thank you again for your time.

[ballardw]

Having run into a number of issues with styles across SAS versions here are a couple of places to look.

First did you rebuild your custom style after the upgrade? If not newer style elements that may be available in 9.4 were not created and likely to default to unexpected font/color/line/marker what have.

If you did rebuild your custom style did the code specify any inheritance from an existing style? If so the base style to inherit from in 9.3 may have changed notably in 9.4. I ran into this with the 9.2 / 9.3 boundary where the same base existed but practically the entire definition was different. So when I "modified" something it wasn't even there to modify. I had to rewrite the style to match the newer base definition.

[dkratz]

Please let me thank you for your response.  You were able to locate the root cause of my attempt to modify the SAS defaults.

What appears to have happened is that in SAS 9.3 lines created by a Proc Report compute block were controlled by the style element notecontent.  In SAS 9.4, those same lines are controlled by linecontent.

So the 9.3 report's custom style was dutifully overriding the behavior of notecontent, which wasn't being used for that bit anymore, causing the line's style to default.

The solution is still the same - to modify the custom style to include the linecontent element

but now I understand why the change occured in the first place.