Find number of pages in RTF document

[NickR]

Is there a way to determine number of pages in a RTF document using SAS?

I tried to read the RTF file into SAS and get the page count based on number of occurences of text 'NUMPAGES'. But this does not work when there is an odd page break (table splits into next page) in RTF file. I tried different ways but no luck.

Any help is greatly appreciated!

[Cynthia_sas]

Hi:
Well, NUMPAGES is something that's only resolved by the rendering word processor application (the app that renders the RTF file -- like Word). So I would not expect that you could read an RTF file into SAS and determine the number of pages the RTF file would display in a word processor.

For one thing, with the original ODS RTF, Person A could open the RTF file in Word and set their margins to HUGE margins -- 3" top and 3" bottom and they would get a different page count than Person B who opens the same RTF file and sets their margins to 1" all around.

I really want to answer your question with a question...WHY do you want to find the number of pages in an RTF document???

If you want to get Page X of Y page numbering you can make that happen using ODS ESCAPECHAR functions like {PAGEOF} for RTF and {THISPAGE} and {LASTPAGE} for PDF and RTF. There are quite a few previous postings and Tech Support notes on the use of ODS ESCAPECHAR functions and performing Page X of Y numbering in the SAS title or footnote for RTF and PDF documents.

cynthia

[NickR]

Thanks for the reply, your explanation was very helpful.

The reason I wanted to find number of pages in RTF document is to programatically determine if there are any odd page breaks (pagination issues) in RTF documents. It becomes difficult to visually find the odd page breaks when working with large RTF files.

Now that I know this cannot be done in SAS, I'll try finding alternatives like using VB code or converting to PDF files and then reading into SAS.

[Cynthia_sas]

Hmmm, well, I would think that reading a PDF file into SAS to determine page count and odd page breaking would be WORSE than reading RTF files into SAS to determine odd page breaking.

Open an RTF file with Notepad -- it's ASCII text -- verbose and icky to parse, but just ASCII text. On the other hand, if you open a PDF file with Notepad, you won't be able to read it. A PDF file is -not- a readable ASCII text file -- it's a proprietary file stored in Adobe binary format.

At least if you open an RTF file into Word and then use a VB script or Word macro on the file, you just have to know how the VB or Word macro will need to fix the file. Assuming you've already spent the $$ for Office, you don't have a lot more expense...but to post-process a PDF file -- don't you need one of the "full" Adobe products??? I'm not sure you can post-process a PDF file with anything but an Adobe product.

You might be able to post-process a PostScript file with a SAS program - -but then you'd still have the issue of converting or distilling the PostScript file into a form that can be opened with Acrobat Reader or a PDF reader.

Probably the best thing to do is investigate the KEEPN option of ODS RTF (which informs ODS to try to KEEP whole tables together if at all possible). Other options that can impact page and table breaking are whether you are using the STARTPAGE= option; and what your margins and orientation are set at.

With ODS RTF and ODS PDF, you have the option to turn STARTPAGE=NO to squish as many tables on a page as possible and then selectively issue a page feed when you need it with STARTPAGE=NOW -- if for example, you have some suspicion that you will need an entire, dedicated page for a particular procedure's output. Sometimes BY groups with the PAGEBY option or PAGE processing on a BREAK statement in PROC REPORT or the PAGE.dimension with PROC TABULATE will end up getting you the size and page breaking you want. It really depends on your procedure of choice and why the odd page breaks are happening.

Sometimes folks try to use old school LISTING techniques like LINESLEFT and N=PS in a DATA _NULL_ program with ODS RTF, ODS PDF and ODS HTML -- and they get odd page breaking that way -- which is to be expected because those techniques are LISTING destination only techniques and do not work with other ODS destinations in the same way they worked in LISTING.

Just some more to think about, I fear, and no real solutions for you. You might want to open a track with Tech Support on this task, as they can look at your current code and the odd page breaking you are encountering and perhaps make some concrete suggestions about what you can do to achieve a report with "not odd" page breaking.

cynthia