* Table auto-sizing

[mcinfhug]

When data is copied from a website page and pasted into an editable text box in FH, the data is formatted as a table, with default values given to the column widths. Depending on the data, this can result in columns having lots of 'wasted' width, and in cells having wrapped display lines.

I laboriously re-size each column to create a compact table with little wasted space and no multi-line cells, and I also delete any unused columns.

The table's Popup menu has a lot of useful options to insert, delete and re-arrange the rows and columns, but it would be very useful (and time-saving) to have an extra option to perform this re-sizing automatically ...
suggestion: Popup>Modify Table>Auto-size Columns

[AdrianBruce]

Not so much auto-size but auto-shrink....

[tatewise]

The term used in Excel is AutoFit.

[mcinfhug]

'Auto-shrink' not appropriate when a narrow column has forced auto-wrap to give two rows of text in one cell.
I envisage similar to LibreOffice's 'Column>Optimal Width' applied to all columns.

[AdrianBruce]

'Auto-shrink' not appropriate when a narrow column has forced auto-wrap to give two rows of text in one cell.
I envisage similar to LibreOffice's 'Column>Optimal Width' applied to all columns.

Actually I was thinking of exactly that scenario - two or more lines of text in one cell. I tend not to mind that if I get a compact set of columns elsewhere, resulting in a compact table that's narrower than the "page".

I guess my preference is for a narrow table with one (say) multiple line column, compared to a wider table, with that one column putting all the text on one line.

I guess providing one could easily transition from the wide (with single lines) to the compact (with two lines of text), I wouldn't have a problem. Too often though, what appears to happen is that I narrow column 1 and instead of keeping the same width for the other columns, moving them in, what happens is the extra width is given to column 2 only, leaving columns 3 onwards the same width and in the same place.

[mcinfhug]

What I am pasting from websites mostly fits in with single height rows, so a one-step auto-size of all columns suits me.

Once all the columns are 'normalized' one can readily then narrow particularly wide columns to give two+ rows of text, having made use of the auto procedure for all the other columns.

It's quite annoying to have to drag each column width, especially if you mis-judge the padding space and the column word-wraps. In some circumstances it's best to initially increase the total table width, before working through the columns from left to right.

Or, of course, don't use the auto-size columns procedure for a particular table !

[ColeValleyGirl]

This seems as if it should be getting more discussion, or at least support? Does anyone object to it?

Also, there doesn't seem to be agreement on how the feature should actually work.

[Vyger]

I would agree with Helen.

Reading the discussion so far Auto fit without some user preference for total number of rows does not appear to provide a good solution.

Thinking of occasional long rows how should such a change help Autofit the majority of user needs without further manual adjustment?

[tatewise]

I don't object to the proposal but it perhaps needs some refinement.

I think the fundamental proposal is that a Modify Table > Autofit option will auto-adjust the width of each column so that it is just wide enough to accommodate all its cell values. That may involve increasing or reducing the width of any of the columns similar to Excel AutoFit.

The exceptional problem is where one or more cells hold long text so its column is very wide, and thus the table becomes too wide. Perhaps a solution to that is to specify a maximum column width (not a number of rows).

Some earlier comments suggest a different solution. After Autofit adjusts columns so everything is on one row, the user reduces the width of any columns that are too wide to force the contents to wrap.
The snag is the adjacent column increases in width by the same amount so the table remains the same width.
If changing the width of one column did not change the width of the adjacent column then this solution would work quite well. For that to work it is necessary that only the column to the left has its width changed, which is how it works in Excel spreadsheets.

Can anyone think of a case where changing the width of one column benefits from a complementary change to the adjacent column? IMO it is usually disruptive to the adjacent column.

[jelv]

I don't think it's that well known that holding the shift key down while you adjust the width of one column, all the following columns move with it with their widths unchanged (the overall table size size is changed). Makes adjusting tables much easier!

Auto fit like the Fit button in AS would be handy though!

[tatewise]

Well John, that is news to me! Where is that feature documented?
It solves the problem of how to post-process wide columns in a table after AutoFit has been applied.

Perhaps there needs to be a Preferences setting that swaps the Shft key mode between keeping other column widths unchanged and keeping the table width unchanged.

Interestingly, there is nothing similar for adjusting row height and keeping the table height unchanged.

[ColeValleyGirl]

Well John, that is news to me! Where is that feature documented?

Not sure it's documented anywhere -- I assumed it was there form day 1, because I'm used to it from MS Word.

Perhaps there needs to be a Preferences setting that swaps the Shft key mode between keeping other column widths unchanged and keeping the table width unchanged.

Or maybe if it was documented, people could make the decision which they wanted at the point of use, like now. I'm not in favour of an option which closes off choices.

[jelv]

Well John, that is news to me!

I've posted about this feature at least twice before and on one of them you replied to me.

search.php?keywords=%2Bcolumn+%2Bshift& ... mit=Search

[LornaCraig]

Not sure it's documented anywhere -- I assumed it was there form day 1, because I'm used to it from MS Word.

CP have to draw the line somewhere, when deciding what to document. For example I don't think it's documented anywhere (in FH) that you can adjust column widths by hovering the mouse over the dividing line and dragging it. They just assume (reasonably) that people know.

[ColeValleyGirl]

Not sure it's documented anywhere -- I assumed it was there form day 1, because I'm used to it from MS Word.

CP have to draw the line somewhere, when deciding what to document. For example I don't think it's documented anywhere (in FH) that you can adjust column widths by hovering the mouse over the dividing line and dragging it. They just assume (reasonably) that people know.

I totally agree.

[mjashby]

Isn't the real issue with 'resizing' table columns a possible lack of full clarity on the purposes behind the requests/questions that have been raised?

Most queries/desires, to me, seem to have been related to on screen appearance, but what may seem 'right' for desktop users with ultra-high definition wide screens may be substantially different to the needs of those users with 'standard' definition screens, or laptops of varying sizes and screen resolutions. Those views also seem to fail to take into account the potential needs of users who may want to design some tables so that they can print those tables to sensibly fit paper of a specific size(s), and also allow for the possibility of portrait and/or landscape output.

However, unless I'm wrong (which is always possible) the Tables which FH7 produces do not appear to be 'true' RTF, i.e. not in a 'format' that any standard Windows and/or other RTF text editors expect/understand. Instead, they seem to be HTML Tables, which may explain some of the issues with controlling column widths and page boundaries; and the need for MS Edge Webview2 to be installed to allow Table editing; and also why full Table functionality isn't currently supported on WINE installations (on macOS or Linux variants) where WebView2 can't currently be used.

Mervyn

[NickWalker]

However, unless I'm wrong (which is always possible) the Tables which FH7 produces do not appear to be 'true' RTF, i.e. not in a 'format' that any standard Windows and/or other RTF text editors expect/understand. Instead, they seem to be HTML Tables, which may explain some of the issues with controlling column widths and page boundaries; and the need for MS Edge Webview2 to be installed to allow Table editing; and also why full Table functionality isn't currently supported on WINE installations (on macOS or Linux variants) where WebView2 can't currently be used.

FH7 and Ancestral Sources both use a fairly up-to-date version of the Microsoft rich-text control for editing. They are not HTML tables. When I last looked at WINE the issue appeared to be that they were using an older version of the rich-text control that didn't support all the features of tables that FH and AS use. Very early versions didn't support tables at all, then table support was added but they couldn't be resized, then later versions allowed resizing, etc.

[tatewise]

As far as I'm aware, MS Edge Webview2 is installed only to support the Web Search Window as a browser.
It has nothing to do with Rich Text. However, I am happy to be proved wrong.

[tatewise]

Perhaps there needs to be a Preferences setting that swaps the Shft key mode between keeping other column widths unchanged and keeping the table width unchanged.

Or maybe if it was documented, people could make the decision which they wanted at the point of use, like now. I'm not in favour of an option which closes off choices.

I was not proposing to close off choices. I was proposing a setting that swaps the non-Shft key mode and the Shft key mode of the column width adjustment.
i.e.
Default: non-Shft key column adjustment keeps table width; Shft key adjustment retains other column widths.
Option: non-Shft key column adjustment retains other column widths; Shft key adjustment keeps table width.
A side benefit of such an option would be Help documentation for the column width adjustment feature.

[jelv]

If this is using a standard MS rich text control I'm wondering if modifying the way it works so that unshifted behaves the way shifted currently works is possible?

Nick, could you answer that as you are much closer to such things than most of the rest of us.

[ColeValleyGirl]

I was not proposing to close off choices. I was proposing a setting that swaps the non-Shft key mode and the Shft key mode of the column width adjustment.
i.e.
Default: non-Shft key column adjustment keeps table width; Shft key adjustment retains other column widths.
Option: non-Shft key column adjustment retains other column widths; Shft key adjustment keeps table width.
A side benefit of such an option would be Help documentation for the column width adjustment feature.

How is implementing yet another option preferable to simply explaining the existence of two options in documentation?

We could even put some guidance in the Knowledge Base ('Tips and Tricks for Rich Text Editing'?) if we didn't want to wait for CP to update the documentation.

[NickWalker]

If this is using a standard MS rich text control I'm wondering if modifying the way it works so that unshifted behaves the way shifted currently works is possible?

Nick, could you answer that as you are much closer to such things than most of the rest of us.

I'm not aware that is possible.

[jelv]

Thanks Nick - as I suspected.

In that case the best thing we could do is follow Helen's suggestion:

We could even put some guidance in the Knowledge Base ('Tips and Tricks for Rich Text Editing'?) if we didn't want to wait for CP to update the documentation.

Perhaps the best start would be a new topic in the Maintaining the Knowledge Base board to get a bullet list of what we think should be in such an article?

[ColeValleyGirl]

Perhaps the best start would be a new topic in the Maintaining the Knowledge Base board to get a bullet list of what we think should be in such an article?

Sounds good.

[ColeValleyGirl]

Related request: Rich Text Wide Table Templates (19589) which led to Fit Rich-Text tables to report page

And also: Allow reports to split very wide tables dynamically (21140) which led to Allow reports to split very wide tables dynamically