* Allow reports to split very wide tables dynamically

[NickWalker]

I've sent this feature request through to Calico Pie and they've said they'll consider this but also suggested it might be a good idea to mention it as a candidate for the wish list here....

In recent updates to FH 7 it is now possible to specify that wide rich-text tables should have their columns narrowed automatically so they fit within the page width. The problem is that for very wide tables, narrowing the columns down doesn't really produce satisfactory results. In the attached PDF (page 1) I've shown screenshots of a 1900 USA census table with Compress Wide Tables turned on and off. When turned on some the columns don't display at all (color, sex, age) and it is generally very difficult to read. When compression is turned off it looks good but a lot of the columns are missing.

I don't know if this is feasible with the reporting system that Calico are using but I think it would be a better solution to have a 'split tables' option in reporting and I've suggested two variants of this: using row numbers and repeating the first X columns.

On the 2nd page of the PDF I've shown how this might look with the row numbers option. The table would truncate at the last complete column, add the numbers column and then continue to display the table below.

On the 3rd page of the PDF I've shown how it might look if the 'Duplicate first X columns' was used with X=1 so that the Name column would be used for each part of the split table.

I'd missed this change but Calico Pie have pointed out that following a recent update it is now possible to split a table permanently within the note editor, but this isn't really satisfactory because there is no problem with a wide table when being viewed in FH, it is only in reporting (and similar) where it becomes an issue and also the table widths may differ depending on the page size or font used for each report. e.g. I might split the table and then find it is still too wide, or unnecessarily narrow when it appears in the report. Also we'd have to do this for every single wide table in every source. So if this could be dynamically carried out when a report was created it would be much better.

Dealing with Wide Tables.pdf

(148.56 KiB) Downloaded 108 times

[davidf]

If the first column contained something meaningful such as a name, your final version is surely to be preferred.

There is another option for tables that are "a little bit too wide" which is to put them on a landscape oriented page, with page breaks before and after. You would need to measure the table and if its width was within the printing height ...

A third (more difficult) option would be (for duplex printing) to page break to an even page, print the left hand side of a table, page break and print the right hand side and then page break again. That would give you a two page wide table on facing pages. Ideally the page break would be at a column break.

[NickWalker]

Yes but the problem with my 2nd option is that in some tables the first column(s) might not be enough (the name might not be in the first column) and also you end up with potentially more table splits because the first column is much wider. I actually think the first option is probably the best one.

I also agree that the other options you mentioned are possible, but we need a solution that works well for users of all levels without them having to jump through hoops to get satisfactory results.

[davidf]

Thinking in a way for which you may not thank me ...!

These wide tables are often created by Ancestral Sources (usually census transcriptions).

Census information often splits into "groups" of information:
- Household relationships
- Personal information: age, occupation, employer, (in US) race
- Where born information: for individual and (in US) for parents
- Education
- etc.

Can these groups be defined in such away that Ancestral sources could actually create a number of separate tables from a census transcription?

[ColeValleyGirl]

These wide tables are often created by Ancestral Sources (usually census transcriptions).

Often but not always, so the solution needs to be outside AS.

[NickWalker]

Yes AS could definitely do things like that, but personally I'd rather have it all in one table which is easy to look at on the screen. I don't need the table splitting up unless it is being printed onto a piece of paper or a PDF.

If we split a table up we're having to make a decision at that point as to how wide the table can be so that it will fit on the width of the piece of paper/pdf with whichever font size I end up using and it will never quite work - tables will either still be too wide sometimes or be far too narrow sometimes (so the table takes up unnecessary vertical space).

Wouldn't it be better to have this happen dynamically?

[davidf]

Wouldn't it be better to have this happen dynamically?

Often but not always, so the solution needs to be outside AS.

Yes, but, ...!

No "dynamic" process will get the semantics right and dynamic column breaks will, according to sod's law, happen in the wrong place and split information (e.g. US "where self/parents born", "where in last census") across a table break.

As with any problem, it is always worth pondering whether you can make the problem "go away" (without introducing new problems) as that is sometimes easier than "solving the problem"?

[ColeValleyGirl]

As with any problem, it is always worth pondering whether you can make the problem "go away" (without introducing new problems) as that is sometimes easier than "solving the problem"?

Yes, but you have to make it go away for all users, not just AS users. It can arise if you create a table using some of the Autotext supplied with FH for example (have a look at the 1950 US census Autotext).

[tatewise]

To help the dynamic process, would it be rational to identify a "preferred split point" on a column boundary?
i.e. Rather like the MS Word "Keep with next" and "Keep lines together" paragraph options.
Actually, that might be a better concept ~ a "Keep with next" option for each column to ensure such columns are not split apart.
e.g. The "Keep with next" column and the following column would be split before both or after both but not between them.

[NickWalker]

To help the dynamic process, would it be rational to identify a "preferred split point" on a column boundary?
i.e. Rather like the MS Word "Keep with next" and "Keep lines together" paragraph options.
Actually, that might be a better concept ~ a "Keep with next" option for each column to ensure such columns are not split apart.
e.g. The "Keep with next" column and the following column would be split before both or after both but not between them.

Yes it might, but in terms of this wish-list I'd like to keep it as simple as possible so it doesn't look like a really daunting major project for Calico. Maybe refinements like this could come along later? Currently a very wide table just can't viewed at all in a report. I don't think it particularly matters which column it splits at personally.

I do understand your suggestion - split the table dynamically but if a 'keep with next' is defined then split the table earlier, but there would be changes that would have to be made to the FTF format used for tables in FH and it isn't obvious how the note editor could indicate this in the rich-text editor. It's all do-able I guess but adds a level of complexity to it.

[davidf]

To help the dynamic process, would it be rational to identify a "preferred split point" on a column boundary?
i.e. Rather like the MS Word "Keep with next" and "Keep lines together" paragraph options.
Actually, that might be a better concept ~ a "Keep with next" option for each column to ensure such columns are not split apart.
e.g. The "Keep with next" column and the following column would be split before both or after both but not between them.

Word processors also tend to have a "header row(s)" function; here it could be useful to be able to designate columns as "header column(s)".

But you still have to have logic to handle if "columns 'kept together' by a keep with next designation" (together with any header columns!) exceed the printable page width.

(HTML+CSS is meant to be able to handle these sorts of situations - being sensitive to different output media and widths - but I rarely see it implemented well.)

[davidf]

Again, perversely thinking laterally:

Is a table still a "valid transcription" if instead of producing rows of data (e.g. one row per person in a census household) you produce columns of data?

With large households you would still have too many columns to avoid awkward word wrapping. But with (English) marriage certificates, I often transcribe: "Header details" then a three column table with headings: Label, Groom Value, Bride Value - I find that fits on screen field boxes better than something word-wrapped.

[David2416]

On the 2nd page of the PDF I've shown how this might look with the row numbers option. The table would truncate at the last complete column, add the numbers column and then continue to display the table below.

My pennyworth:
That looks like a good solution for starters. Refinements could come later once the initial issue is satisfactorily handled.

[ColeValleyGirl]

Again, perversely thinking laterally:

Is a table still a "valid transcription" if instead of producing rows of data (e.g. one row per person in a census household) you produce columns of data?

Source from Text doesn't have to be a transcription -- it could be an abstract, for example. But it ought to be capable of being a transcription, and for those like me who don't publish images, having a table that mimics the original is useful.

[NickWalker]

Again, perversely thinking laterally:

Is a table still a "valid transcription" if instead of producing rows of data (e.g. one row per person in a census household) you produce columns of data?

With large households you would still have too many columns to avoid awkward word wrapping. But with (English) marriage certificates, I often transcribe: "Header details" then a three column table with headings: Label, Groom Value, Bride Value - I find that fits on screen field boxes better than something word-wrapped.

It would be a reasonably straightforward enhancement to AS to have it invert the grid so the column headings were displayed downwards but really this isn't about AS (as Helen has said). And as you've said this won't solve the problem anyway because there will still be times that the table won't fit and so there still needs to be a solution to that.

[jimlad68]

It would be a reasonably straightforward enhancement to AS to have it invert the grid so the column headings were displayed downwards...

This is a way to keep all the info for one person together, it would probably need a lot more space, and using Landscape mode would probably limit to around 5 people ##edit > per section, but it could be repeated as amny times as required ##

In the past I have used the method below, each column would have more than 1 item, but it means 1 row per person:

temp.png (37.39 KiB) Viewed 2673 times

For the latter version some of the table borders could be dotted to show separation within an individuals detail.

[arthurk]

I've been thinking about this kind of issue recently - see Text from source - tables in reports (21275), where Nick kindly gave a link to this thread. I agree that wide tables have been a problem, but is splitting the only solution?

When a table is too wide there seem to be 3 possibilities with the current FH settings:
(a) it spills off the side of the page
(b) it shrinks to the size required, which in many cases will mean long words getting split in odd places and without a hyphen because their cell is now too narrow
(c) the table is split into two parts at a point chosen by the user (new in v.7.0.18)

I'm not sure if (c) now meets the requirements of this request, but even if it does, I'd prefer it if tables didn't split at all. That means sticking rigidly to a maximum width of table, and almost certainly making the text in it smaller, and the latter can be a bit tricky.

The font for the sources section of a report is set in the formatting of Section Data, but any change will be applied to the main body of the report as well, which seems less than ideal.

However, reducing the font size in the rich text editing window isn't usually an option, as the dropdown menu doesn't let you select a size smaller than the current default.

There are a couple of workarounds:
(a) go to the raw text editing window, where it is possible to set a smaller font size - but the way to access this window isn't publicised as it's not intended for the average user
(b) select an alternative font for the table which when using the default size comes out smaller than the one set in the report options

I've been experimenting with alternative fonts and initial findings look fairly promising, but it would have been a lot simpler if either or both of the following were possible, which I suggest might be alternatives for the wish list:

1. In the rich text editing window make it possible to select a font size smaller than the current default/automatic setting.

2. In report formatting options separate the font settings for sources from those for the main body of the report, so that a different font/smaller size can be selected just for sources.

Presentation is important, and if these things can be done, I believe this would in many cases be the best solution.

[NickWalker]

Font size is not an option when a table is wider than the page size available and the size of font is reduced to a size which is unreadable. e.g. size 2 font. It also very much depends on your page size.

I think everyone would prefer that tables don't split, but this request is for times when this isn't possible. If the table spills over the width of a page then I'd prefer it to split than to truncate. That seems like a reasonable option to have available and you wouldn't be forced to do this.

If I'm printing to A3 then the table wouldn't need to be split. If it was printing to A5 it most likely would. Hence why it needs to be dynamic.

If you want to create a wish-list for better control of fonts then please add it as a new wish list request.

[arthurk]

If you want to create a wish-list for better control of fonts then please add it as a new wish list request.

OK - understood

[davidf]

In word processors you can print wide tables in landscape mode:

• Section break
• New section - Format - Landscape to hold the table
• Section Break
• Continue in portrait mode

Won't solve all problems - but may solve a useful number?

[ColeValleyGirl]

I've sent this feature request through to Calico Pie and they've said they'll consider this but also suggested it might be a good idea to mention it as a candidate for the wish list here....

Nick, any chance you can find the time to turn the result of this discussion into a Wish List entry that I (or Mike) can just lift and copy?

Even if there are alternative ways of working to achieve the same objective in some circumstances, this feature specifically doesn't exist, so ought to go onto the Wish List for voting. Especially as you've already sent it to CP...

[NickWalker]

How about:

Tables in source text or notes when displayed in reports can be too wide to fit on the page, particularly when 20th century census records are transcribed. Changing font size or narrowing the columns will usually not help in these situations. Splitting the table up within the source text itself would be possible but is not desirable as there is no need to split the table when viewing it normally in FH. Furthermore, there would be no need to split the table if viewed on larger page sizes such as A3.
We would like a report option to be available to automatically split a table when it becomes too wide for the page. Probably the best option being to add numbering to the rows to make it easier to see the matching rows across the split.

[ColeValleyGirl]

Wish List Item 586 has been raised for this.