[Feature Request]: Helper for wrapping first column to reduce white space

[llrs-roche]

Feature description

First column of summaries tend to have lots of labels and levels. They might be of different length resulting in some places with lots of empty space at the level too:

Adding new lines fixes one but might not be enough as other levels might be longer than the new shorter lines:

I think the ideal solution would take the length of the labels, the length of the levels, where empty spaces can be replaced by new line, how this would affect the line length and the indentation of the levels.

A function could format the first column so that the new line is placed in all labels that need it to reduce the white space after the levels till the next column. But with long and complex names it might be hard to break them. Something like formatters::propose_column_width() or one step further to actually modify the labels (modify_characteristic() ?)

Code of Conduct

• I agree to follow this project's Code of Conduct.

Contribution Guidelines

• I agree to follow this project's Contribution Guidelines.

Security Policy

• I agree to follow this project's Security Policy.

[jszczypinski]

Based on some research I believe that formatters::propose_column_width() will not suffice for crance since gtsummary objects do not keep column width as arguments and its the flextable which controls column width.

One way would be to add an extra argument and pass it to flextable.

But I believe it is a better idea to do a function as you proposed - modify_characteristic()

It can be quite easy using e.g. stringr::str_wrap()

[llrs-roche]

I haven't thought about stringr::str_wrap()! Thanks for the comment, I might see if I can implement the algorithm there instead of importing the heavy dependency of stringi (as we also don't need hyphenation) and page breaking would be defined at the row level not one cell content (imho).

A good explanation is this one: https://github.com/jaroslov/knuth-plass-thoughts/blob/master/plass.md

[jszczypinski]

You are right - we should omit adding stringi. The function can be a good reference though :)

[Melkiades]

I haven't thought about stringr::str_wrap()! Thanks for the comment, I might see if I can implement the algorithm there instead of importing the heavy dependency of stringi (as we also don't need hyphenation) and page breaking would be defined at the row level not one cell content (imho).

A good explanation is this one: https://github.com/jaroslov/knuth-plass-thoughts/blob/master/plass.md

I think stringi is quite common, and a dependency of rtables so there is no harm in adding it as dep (stringi is light in comparison to stringr).

I rewrote the wrapping algorithm with str_wrap from stringi. Writing that algorithm to allow also breaking words when extremely long words were added was a nightmare with recursive calls and complex conditions to make it work nicely. I would not go through that rabbit hole again if you can avoid it (it seems fun but it is very difficult to maintain too)

As for the example above, we would keep the first example instead of the second as the priority is (1) readability of results (fixed by Jan) and (2) space occupied. I can see the second example being longer for no clear gain, only loss of available margin.

@shajoezhu what do you think?

[llrs-roche]

@Melkiades The first screenshot is without addressing the request from a user, the second is naively adding a new line to the longest line hoping to reduce column width. I agree this is a bad approach, that's why I propose here to avoid this manual tweaks that do not solve the issue .

One problem with stringr::str_wrap() and stingi::stri_wrap is that both functions require a width. In our case we don't know the width, we only now that we want to minimize the space difference between levels and labels, so that text is broken into pieces that make the column and thus the table less wide. This is a bit different from the algorithms implemented on these functions

I agree this can be quite complex and I don't take this lightly, at the same time users will keep asking for improvements on line length until we can "prove" them that there is no better solution and we can push back.