-
Notifications
You must be signed in to change notification settings - Fork 214
Fix Issue1656 #1716
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Issue1656 #1716
Conversation
When available, assign an explicit width to multicolumn statements to comply with user-specified column widths.
Kenneth Brevoort seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
This looks great @kbrevoort ! I’ll review this shortly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
This looks great! Let me know if this is finalized (i.e., no more commits coming) and I'll then merge. |
I'm assuming this is good to go, so I'll merge right now. Thanks! |
Great work! I've noticed issues when using pct as unit: Setting column widths to percent off by a factor of 100:
Intermediate Latex code:
setting
Intermediate LaTex code:
Intermediate Latex code:
|
Really appreciate you tackling this, thank you!!!
|
Thank you, @nielsbock & @bzkrouse ! I appreciate you pointing these out so quickly. @bzkrouse , do you have an example you can share of the second issue you've seen (the -2's)? I haven't been able to reproduce that one. |
I think the issue is that adding a group header when table width is set to, say, 100%, an unescaped "%" is added in the latex code, which causes an error. I don't have access to a PC right now, so I can't give an example. I tried removing the "%" in the code in my own repo, but even then, the new code for group headers does not work properly. |
@kbrevoort Thanks for the reply! To be more specific, when I render your example code to pdf within Rmarkdown it produces the -2's. If I render within Quarto, all seems fine. |
@kbrevoort Just to add a bit more context, the gt/tests/testthat/test-fmt_fraction.R Line 524 in bf3ffd6
|
Thanks, everyone! I've just submitted a PR that should address all of these issues. |
Summary
The Issue
Issue #1656 describes Latex behavior in which a column spanner with a long label can override user-selected column widths. For example, consider the following MWE
`
title: "gt_tester.qmd"
format: pdf
`
In this example, each column width is set to 2cm. Yet, some of the spanners contain long labels, Latex overrides the user-requested widths to accommodate them. As a result, the result using the current {gt} version looks as follows.
The long spanner labels are not wrapped, and the columns are now so wide that the table runs off the page. While Issue1656 presents this as an issue with using column spanners, the same problem results any time a
multicolumn
function is used that spans more than a single column (when a multicolumn command spans a single column -- which does happen in {gt}'s Latex output -- any specified column width is retained by Latex).The code in this pull request fixes this using the workaround suggested by @bzkrouse (who filed issue #1656), in which the width of the multicolumn is explicitly specified when it is available. I think that's the best approach. As a result, the same Quarto file above will generate a PDF that looks like this.
Note that the long column spanner labels now wrap, and the column widths are retained
How the new code works
I've moved a block of code that used to be included in
create_heading_component_l
, which calculated the width of each column, into a new functioncreate_colwidth_df_l
. This function is called near the start ofas_latex
. It returns a data.frame that has one row for each column in the table and three variables that measure the column width. This data.frame is passed tocreate_heading_component_l
and other functions that use multicolumns.For each row in
colwidth_df
, widths are represented in one of three ways. The column width can be unspecified,unspec == 1L
. If the column width can be represented in points (the length used by Latex), this is stored in variablept
. The last option is if the width has been expressed as a percentage that cannot be converted to a specific point value, in which case the width is output as a percentage of the available space (represented in Latex as \linewidth). One and only one of the three variables (unspec
,pt
, andlw
) has a nonzero value. (Note, the values stored in colwidth_df are not necessarily those supplied by the user. For example, if the user sets a column's width to "25%" and sets the table width to 6 inches, colwidth stores the width as 1.5 inches converted to points.). When outputting a multicolumn statement, {gt} combines the column widths from this table and uses them to set the width of the combined cells.I also made a semi-related change that's worth noting. In the MWE above, if row_group_as_column == TRUE, the current {gt} code results in an error ("Extra alignment tab has been changed to \cr."). I've corrected this behavior in this pull request and added a
multirow
command that allows the group label to overlap the rows of the group, as in the screenshot below.As part of this change, I have added the multirow Latex package to the list of required Latex packages.
Related GitHub Issues and PRs
Fixes: #1656
Checklist
testthat
unit tests totests/testthat
for any new functionality.