* Narrative Report Source Text Table issues

[mezentia]

Apologies if this has been asked before, but does anyone have any practical suggestions as to how to circumvent RTF autotext tables from being truncated on the right-hand side of a page in the Sources section of narative reports? I wish to send a narrative report to a co-researcher, but manually editing 47 pages of sources with up to 3 tables per page needing manual editing is a rather daunting task

[tatewise]

That is a known problem that has been raised before with no easy solution.
I believe it has been reported to Calico Pie.

The only option is to edit the Rich Text Tables by hand or change the Rich Text fonts or the fonts used in Reports to a smaller point size and use landscape pages.

I think Ancestral Sources has added some features when creating Rich Text Tables for say the Census grid that allow the column widths to be adjusted before saving to FH.

[mezentia]

Hi Mike,

I have tried swapping to landsacpe and reducing the text size to try and overcome this problem, but it does not make for an attractive or particularly readable report. I have touched on this with Nick on the AS board, and suggested that within AS we could nominate a column as a "break column" within the template for the specific entry, but I suspect that there are too many variables involved in actually implementing this, not least end-user choices in respect of text style and size that might override template settings.

I wan't sure if it had been reported as an issue, but I'll do so and add my small weight to the pressure to come up with a solution. An option to "fit to width" for tables could help possibly if the page overflow is small, but when we get to the large number of columns on some US censuses or passenger manifests even this would not be a workable option.

The ideal would be that when rendering a table within a report, if a column would overflow the right-hand margin, then the entire table is wrapped at the previous column, and, optionally, a pre-selected number of colums from the left of the table output before resuming to output the remaining columns, with that process repeated until the entire table has been output. This would allow line numbers or sub-schedule numbers, for example, to be printed at the left of each table section.

David

[tatewise]

Yes, some sort of table wrap would be a solution, perhaps with the option of repeating the 1st column in each wrapped table fragment as the 1st Column is usually the 'key' for each row.

[NickWalker]

Yes AS does have a 'fit' button that automatically scales census columns and this helps a lot but doesn't solve the problem for wider/later census records.

I did make the suggestion during FH7 testing to split the table over multiple rows. It is something that I might end up doing in AS but I'd prefer to wait a little while to see if Calico solve it.

The problem with doing this in AS is that the tables would then be permanently broken which would be frustrating if, for example, you wanted to print the source text on wider paper, in a PDF, etc. which might be perfectly capable of displaying the full width. So really it would be much better if Calico dynamically split the table based on the page size and font size chosen, etc. Also although it would be reasonable straightforward for me to implement this for the census table, it wouldn't resolve the issue for other less formally structured tables that might be in birth or death records for example, although I suspect they will be less of an issue.

Cheers

Nick