Question about titles and footnotes in the body of the document

[ghost]

Hi Eli,

This is a really great package!
However, my company standards dictate that

outputs must not include any text in the header or footer, as they are reserved for regulatory publishing.

Is is possible to do this with pharmaRTF now? Or could it be sometime in the future?

Thanks!

[mstackhouse]

Hi @Robert-Krajcik,

Currently, pharmaRTF leverages the headers and footers as the most straightforward method of handling paging - as opening the document in a reader automatically interprets the paging properly. Implementing output of the document without using the headers and footers would actually be a substantial overhaul for a number of reasons.

If we have enough interest in this feature, we can look at addressing it.

[mstackhouse]

This issue has been raised by several different individuals, and I think that's it's probably on the critical path for pharmaRTF. The most common piece of feedback that we've gotten on it is the use of document headers to cheat our way through paging. My understanding is that people want the headers of columns inside the body of the document rather than the document header. {gt} does this using the \trhdr option, but I'm not sure it's 100% what people are looking for, because when you try to copy the text, the header still appears only appears at the top of the doc.

Furthermore, there's another situation this wouldn't account for. SAS has the ability to rotate through pages different pages using PROC REPORT in case you have something like 20 columns (think a trial with like 15 treatment groups). Having this many columns isn't necessarily "best practice", but it may not be avoidable, and any of us who have worked on tables or listings know that it just happens every now and then. So it's not unreasonable to think people would want the document to basically go:

• Page 1 columns 1 - 10
• Page 1 columns 11-20
• Page 2 columns 1 - 10
• Page 2 columns 11-20

And so on. So this is by far outside the current capabilities of {pharmaRTF}. But if we address the paging issue, then this is honestly only a small leap. The crux of the paging issue is understanding the size of everything. The page, all the margins, and most importantly the text that we're writing to the page. Meaning - really we just need to make sure that the data we want to write fits. In order to do that, we need to understand how large the text is on the page itself - in the actual physical measurement.

A proof of concept of this can be seen as below:

#' Get the height and width of a string given a font family
#'
#' This function takes a text string and a base R font famil¿y and returns the
#' height and width of the string in inches
#' 
#' Tested on OSX, the following fonts seem to work ok:
#'   - serif
#'   - sans
#'   - mono
#'   - Courier
#'   - Helvetica
#'   - Palatino
#'   - Times
#'   - ArialMT
#'
#' @param text Character string or character vector
#' @param font_family Font family to use for sizing
#'
#' @return Named character vector with elements for height and width
#' @export
#'
#' @examples
#'
#' get_font_hw('hello there!', 'sans')
#' get_font_hw('hello there!', 'Courier')
#' get_font_hw('hello there!', 'ArialMT')
#' 
get_font_hw <- function(text, font_family) {

  return(
    c(
      height = strheight(text, units='in', family=font_family),
      width = strwidth(text, units='in', family=font_family)
    )
  )
}

Example code as executed:

> get_font_hw('hello there!', 'sans')
   height     width 
0.1195475 0.8246257 
> get_font_hw('hello there!', 'Courier')
    height      width 
0.09651693 1.20019531 
> get_font_hw('hello there!', 'ArialMT')
   height     width 
0.1193034 0.8246257 

From there on it becomes a matter of translation to the current font size. I need to trace what the default sizes are and how those would populate within the RTF document. Once that's understood, everything can be mapped into the input table, and the table can be chunked up appropriately. This would allow separation of individual pages of the RTF, and separation of columns of the RTF - even accounting for string wrapping of long running strings, where we can anticipate a line wrapping within a cell.