- I am no longer using RM’s Place Details feature. The Details part of the place is now included instead in the main Place field. I made this change for compatibility with third party genealogy software.
- I shared marriage and divorce events with each of the spouses. This has the practical effect of listing marriages and divorces in timeline order for each person, in addition to listing the marriage and divorce in the family section of the report for each person. The version of the marriage event in the family section of the report includes a note with a transcription of the courthouse marriage record. The version of the marriage event in the individual section of the report has an empty note. Normally, I don’t use RM’s shared facts at all because they are not compatible with third party software. Indeed, my use of shared facts for marriage and divorce events is not compatible with third party software, either. But I don’t care because the only thing my use of shared facts is accomplishing is to improve the appearance of my narrative reports. No actual data is lost if the shared facts are lost.
- I added bold font introductory words into many of the fact notes. For example, for the death fact my new sentence template for the death fact introduces the fact in bold font as “Death:” without the quotes. I have always included obituary text as a part of the note for the death fact. So I changed the death note slightly so that the obituary starts out as “Obituary:” without the quotes for the text of the obituary. Therefore, there is parallelism of format for the fact sentence and the fact note. Indeed, the changes I have made suggest to me that the obituary text might work better as its own separate fact, and similarly for information in many of the other fact notes. That way, I could include or not include obituaries in reports by including or not including my proposed obituary fact. I can do the same thing now by including or not including fact notes, except that including or not including fact notes right now is all or nothing. If fact notes such as obituaries in the fact note for the death fact became their own separate fact, then I could be much more selective in what I do or do not include in reports.
- I thinned out my sources by deleting many citations that are of lesser quality than other citations or which simply provide duplicate information from other citations. In many cases, I had as many as 15 or 20 citations for a particular person or fact. I’ve tried to get it down to the most important 2 or 3. This project is not complete, but I’ve improved my source list a great deal.
- I’m continuing to convert all my sources to using templates of my own design rather than using the Free Form template. This project is also not yet complete, but as I make progress with the project it greatly improves and standardizes the quality of my footnote sentences. Despite using RM’s template facility, my footnote sentences are fully compatible with third party software because my source templates cause my citations to be completely split - not using the Details portion of RM’s sources at all.
- I halfway figured out how Microsoft Word handles styles – finally! Therefore, I used Microsoft Word’s styles to improve the appearance of the person index and place index at the end of the report. I reduced the overall font sizes in the indexes, and I bolded and increased the font sizes for the highest level in the indexes. I think the result is quite nice. In the process, I discovered that Microsoft Word has a nasty limitation in its support for indexes. Namely, if there are multiple indexes then all the indexes have to use the exact same style. This limitation doesn’t matter for my report, but it matters greatly for some kinds of academic publishing where there may be many, many different indexes and the indexes may need to use different styles.
- My reports are in the NEHGS format (Register format). This format is by generation. It includes a list of children for each couple, and it carries a child forward to the next generation only if the child marries or has children of his or her own. In previous years, I have used a trick with SQLite to carry certain individuals forward to the next generation even if they don't marry or have children. The reason for this procedure is that there is a great deal of information in the report for some of the individuals who are not carried forward by default by RM. The extra information does not look very good in the list of children. For this year's report, I greatly expanded the number of people who are carried forward to the next generation in this manner. The sample report includes one such person - namely Johnny Clyde Peters who died as an infant - so you can see how this effect actually looks in a report.