Calculate the horizontal and vertical sizes, in millimeters, of the text
strings in a prEntries object. This is an internal function, not
intended to be called by package users.
entrySize_mm(entryInfo, allowWrap, sizeAdjust=c(1, 1))Data frame with the same row names as entryInfo, and columns:
hsize and vsize containing entry dimensions in millimeters;
horiz (logical, TRUE if entry angle is 0 or 180 degrees);
descender (amount of space included in hsize (if
horiz is FALSE) or vsize (if horiz if TRUE) to allow
for descenders); and wrap (logical, whether text needed to
be wrapped to satisfy maxwidth).
The data frame has an attribute device, containing the name of the
graphics device used when calculating text sizes. (Currently this is
always "pdf".)
A prEntries object, currently implemented as a data frame with one
row per table entry. It must include columns text,
textspec, maxwidth, and properties size,
family, fontface, hpad, vpad, angle,
and lineheight. size should be in points, angle in
degrees, and lineheight should be specified as a multiple of text
size (see ?grid::gpar).
Logical scalar. If TRUE, entry sizes will be calculated after any text
wrapping required by entryInfo$maxwidth.
Two-element numeric vector containing multipliers to adjust the calculated
absolute size of table text. The first element is applied to the
horizontal dimension and the second to the vertical dimension. Ignored if
allowWrap is FALSE.
The dimensions are for an unrotated rectangle that just encloses the
(possibly rotated) text. (So hsize is always measured parallel to
the x-axis and vsize parallel to the y-axis; i.e., they are with
respect to the reference frame of the whole table.)
This relies on the functions grid::convertWidth and
grid::convertHeight. They require that a graphics device to be
open. It would be natural to use the currently active device, if any, but
this seems to generate empty pages on that device. Therefore a temporary
PDF device is silently opened, and then deleted at the end.
String sizes may vary slightly between different graphics devices, even with the same graphics properties (font size, family, face, etc).
The height of text processed with richtext_grob or
textbox_grob differs from the same text processed with
textGrob: (a) The former includes the height of character
descenders (whether or not the text actually includes characters with
descenders), whereas the latter does not. (b) Interline spacing seems to
be smaller with the former than with the latter. Descender height is
returned in column descender; it will be 0 for text not processed
with richtext_grob or textbox_grob.