Thanks I appreciate your continued interest in helping here. The real problem for me with both of your approaches is that you need to know the cell height before generating the table, so that it can be hard coded into the proc report step. In my real application I have a piece of SAS code that is supposed to run and generate a PDF file based on data that is dynamically refreshed every day, having text fields of variable lengths that need to fit into cells in the report, and I won't be able to guess the length of these fields in advance to hard code them into the SAS script -- it all needs to be driven from the data. It is an automated process, and I can't be reaching into the code every day and fiddling with it until it looks right. That is why I was hoping that the PDF generation step could just take care of the proper sizing of the cells, as it should be able to. Given that this bug in proc report with PDF destination isn't going to be fixed soon, and there is no convenient workaround, I either need to accept the badly formatted tables or else come up with a way to dynamically figure out how high each cell ought to be to fit all the wrapped text, and apply the proper sizing to each row. I'd need to do this dynamically within SAS code in a data step or something. I can imagine how the code would look, but the logic would be very complex and annoying to write involving counting characters, finding word boundaries, figuring our where the lines would wrap, and then comparing that with how much space you can anticipate having given the lengths of other "grouped" fields later on in each row... I'm sure this code wouldn't be robust 100% of the time. This kind of thing is what you're supposed to rely on proc report itself to figure out (for instance, if I were using RTF instead of PDF I am told this just works). anyhow thanks again. I do appreciate it!
... View more