Family Historian User Group

A problem I have, which indidentally pre-dates the release of FH V7, is that when using AS to generate auto text from, specifically, census entries, and predominantly US and Canada census entries, the generated text does not fit on a page. The table requires subsequent manual editing so that the census entry can be split such that it will fit within the printed page's margins. This raises two questions.

First, when rich text is generated, there is a Fit button that sizes the columns to fit the text contained. However, this seems to work on the principal of fitting all text onto a single line. In fact, the column heading text is often wider than the column contents. To help create a narrower column, I manually resize the column such that the column heading text occupies two, sometimes 3, rows of text. Would it be possible to re-define the Fit button operation such that it fits the text from the table cells containing the data, and wraps the heading text to fit the newly calculated width. Alternatively, where the data is wider that the column heading, would it be possible to double click on a cell boundary to cause an automatic column resize thus removing the need manually to drag cell boundaries across the page?

Second, the table can be extremely wide. Would it therefore be possible to define within the census template:

(a) one or more colums on the left-hand side of the table to be classified as row headings, and
(b) selected columns within the rest of the table as break columns, such that when a break column is encountered the table is split at this point with the row headings repeated on the left hand side of the table and the columns following the break column continuing until another, if any, break column is encountered.

It is clear from censuses such as the US 19430 census, for example, where some census entries have additional information, that the generated table can contain close on 70 coumns if every column from the original is transcribed.

I think really the issue is that reports in FH don't automatically split tables when they reach the right-hand margin. If you were printing a report on an A2 printer, for example, then you might be quite happy to have very wide tables! Table width is really related to the format and medium in which the data will be presented, which could vary depending on how you are presenting your data in future. I did make this suggestion during Beta Testing of FH so presumably Calico do have this in their list of possible enhancements in future.

Certainly the table splitting being done by AS is something I've considered and will continue to think about. I'd envisaged it splitting automatically when a user-defined 'maximum width' was reached, rather than 'hard-coding' the column breaks into census templates which would be time-consuming and more difficult for users to configure. Do you think that would work for you?

I assume you are doing all the column width changes using the main census grid, rather than the one in the source text? It's certainly a lot easier to manipulate than the 'rich text' table. I don't think it would be technically possible (or at least it would be tricky) to make the table work with double-clicking boundaries in the way you suggested (double clicking a boundary in the grid automatically performs a 'fit' on the column). You could just set the column widths to be much narrower in the census templates and not adjust the column widths or use the Fit button?

As the saying goes, there's more than one way to skin a cat - if you don't mind the reference to feline taxidermy

My first thoughts were that it is more common for narrative reports to be printed on A4, and given the relative ease of working with census templates, the column break would be a simple solution. Clearly I did not think things through enough, and an auto-wrap would be a neater and more general solution. Having worn the hat of software designer in the past, I never failed to be amazed at what end users try and get programs to do that the software was never really designed or intended to do.

I do do quite a bit of work on the census templates, and I do tweak the column widths there, but this is more to get the main grid display usable . Too narrow a column can make data entry more difficult, particularly when there is a drop-down list button that can occupy a substantial part of a column's width. As a result, I tend to work on the columns after creating the auto text.

I appreciate that the end-user's choice of font would complicate matters, but again I assumed that most people would tend to use the defaults.

My suggestion about double clicking on a column boundary came from my previous experience with Microsoft Excel.

I've not 'officially' released v7.1 yet and have now just updated the download to 7.1.2 here: Ancestral Sources v.7.1 to correct a couple of issues prior to announcing the release. I've now added a new 'fit' option which if selected will ignore the width of the column titles when autosizing columns (i.e. just fit to the widest text in the rows other that the header). Thanks for the suggestion.