topic Re: Corrupt RTF file produced by ODS in ODS and Base Reporting

Corrupt RTF file produced by ODS

BruceBrad — Tue, 26 May 2020 09:36:27 GMT

I'm finding that some of my RTF files are being reported by Word as having corrupt tables. There is no error message in the log file of the SAS program that created them. I'm not using any special formatting commands other than {NEWLINE} statements in tables. The tables are quite large however. Any solution to this?

Re: Corrupt RTF file produced by ODS

Kurt_Bremser — Tue, 26 May 2020 10:11:15 GMT

Open the files with an alternative, like LibreOffice. If that also chokes on the files, open a track with SAS technical support, as you might have uncovered a problem in ODS RTF.

Re: Corrupt RTF file produced by ODS

ballardw — Tue, 26 May 2020 11:27:37 GMT

Did you try it without the {newline}?

It might help to show at least the code used. And since this is an ODS issue include the ODS RTF along with whatever table generating code you use.

Word does enough all by itself on "corrupting" large complex tables. So you also might consider whether a set of simpler tables would do.

Re: Corrupt RTF file produced by ODS

BruceBrad — Tue, 26 May 2020 12:10:41 GMT

Thanks for the LibreOffice tip. It does open in LO, but the table is nonetheless messed up. See below.The years should be in the second column (which they are for the other family types not shown). However, it does look like I was on the wrong track thinking about the RTF output. My program also writes xlsx and html, and it is messed up there too. So is this a proc tabulate problem? An excerpt of my code is:

options ls=max ps=max;
options papersize=A4 orientation=portrait;
ods _all_ close;
ods graphics on /reset=index height=11.5in ;
ods rtf  style=bbfp file="&Output\Trends.rtf"  image_dpi=300 bodytitle;
ods html style=bbfp path="&SASImages" gpath="&SASImages"  image_dpi=300;
ods Excel file="&Output\Trends.xlsx" style=BBfp options(sheet_interval='NONE' embedded_titles='yes')  ;
ods escapechar="~";  /* used to insert special formatting commands, like {NEWLINE} */

[cut]

proc tabulate data=dat1 style=[cellwidth=75];
  weight w1;
  class surveyyear hhstruct21 H_IS;
  label surveyyear=;
  label hhstruct21='00'x;
  label H_IS='00'x;
  var Y one;
  table  hhstruct21*surveyyear='' ,
        (H_IS all="All people")*
        (p10 p20 median mean)*f=comma6.0*
        y=""
        /  row=float
   ;
run;

Re: Corrupt RTF file produced by ODS

BruceBrad — Tue, 26 May 2020 12:39:40 GMT

Removing "/row = float" and replacing with "/nocellmerge" fixed the problem. (I didn't really need the row titles to float, but did want the cells in the xlsx output to be not merged). Incidentally, row=float was not a problem for my smaller tables - it just seemed to produce problems for large tables.

Re: Corrupt RTF file produced by ODS

ballardw — Tue, 26 May 2020 13:47:49 GMT

@BruceBrad wrote:

Removing "/row = float" and replacing with "/nocellmerge" fixed the problem. (I didn't really need the row titles to float, but did want the cells in the xlsx output to be not merged). Incidentally, row=float was not a problem for my smaller tables - it just seemed to produce problems for large tables.

You might also look at why you tried to set

style=[cellwidth=75];

Especially without specifying a unit for the width.

I have had the problem with tables displaying the way you show, some columns on some rows not aligning correctly but for me the fix was row=float.

The "labels" of '00'x might partially be an issue as well but without data to test anything I can't say for sure. Why are you using those labels?

Re: Corrupt RTF file produced by ODS

BruceBrad — Wed, 27 May 2020 00:19:28 GMT

Yes, I should specify units on the cellwidth. (The doc suggests the default is 1/150 inch).

The '00'x labels are to remove the labels for these variables. This does seem odd, but I haven't found a better way to do it.