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