27 replies to this topic

[Jerry Bryan]

The most important thing I do with RM is to produce descendant narrative reports for family reunions. I print these reports on paper and I bind them informally in report binders. I make a copy for every family at the reunion. I just finished producing the report for this year’s family reunion for the descendants of one of my ancestors. I hope eventually to convert some of these reports into published books on paper that are professionally printed and bound. 

 

In general, my comments about using RM this year are very similar to what it has been in previous years. RM does some aspects of creating my reports very well. For other aspects of creating my reports, RM could certainly use some improvement. 

 

The biggest change in my report this year is that all the sentence templates are now much more terse than the RM default. It’s hard to get RM's narrative reports to read very smoothly anyway, so I decided to use things like “Birth: 1 Jan 1904.” without the quotes for birth sentences, etc. The name of the fact is bolded and followed by a colon. Doing it his way gets rid of the issue of whether to use full names or short names or pronouns in sentences and the repetitiveness thereof. Also, I decided to go with noun versions of event names rather verb versions of event names – e.g., “Burial:” without the quotes vs. “Buried:” without the quotes. 

 

You can see for yourself if you like the effect at https://www.dropbox....report.rtf?dl=0. This sample report is like the real report from the reunion, except that it only includes two generations and I privatized the children in the third generation who are still living. The real report has seven generations and nobody is privatized.

 

Other changes for this year: 

 

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.

Jerry

[Renee Zamora]

I didn't think I would like your report because I was so use to a narrative. Once I looked at it I changed my mind. It is beautiful and clear to read. You did a marvelous job.

[zhangrau]

I downloaded your RTF file and opened it with Word 2003 - no problems. I think it looks good, although it's very different from the reports I've been printing. I could get used to it !!

[TomH]

Great piece of work, Jerry! Clear, easy to read, even when opened in Dropbox on an old iPad with iOS 7. So many good ideas. One I had talked about but have yet to implement was the conversion of fact sentences from full sentences (subject, verb, ...) to point form. I really like what you have done with the bolding of the fact type. 

[Lethdun]

Really nice, Jerry! You've done so much that it is hard to pick a favorite item. For me, I think I might need to rethink.

 

Tom

[windstorm]

I really like the changes you made in the report, much easier to read IMO. 

 

Forgive me if I am overlooking this, but when creating a custom text for each fact type, is there a complete list of phrases somewhere that can be used to make the template, such as the <[date]> etc... or is it a try to find it as you need it thing at this point?

[kbens0n]

is there a complete list of phrases somewhere that can be used to make the template, such as the <[date]> etc... or is it a try to find it as you need it thing at this point?

Some detail can be garnered from the Help facility. Search on:
-> Sentence Template Language

[Jerry Bryan]

Some detail can be garnered from the Help facility. Search on:
-> Sentence Template Language

 

In addition, study the built-in sentence templates by going to List->Fact Type List.... . You can see how they use the various tags such as [Date] and [Place]. You can also see how they allow for missing data by using the angle brackets <....>, for example, the built-in sentence templates use things like <[Date]> rather than just [Date] to allow for the date to be missing without messing up the sentence.

 

I thought I had posted a sample of my sentence templates, but apparently not. Here is my Birth sentence template.

[Person:Full].
<b>Birth:</b>< [Desc]>< [Date:Plain]><,< [PlaceDetails]>< [Place:Plain]>>.

There are several points of interest with respect to the templates.

1. Since I took the person's name out of all the sentence templates except for the birth template, the person's name will only be appearing one time. So  I made sure to specify [Person:Full] to get the person's full name listed. I think it would have been fine anyway with just [Person], but I wanted to make sure.
2. Sentence templates can include carriage returns, so I put the birth information on a different line than the person's name - like the name is one fact and the birth is a different fact.
3. Sentence templates can include include a limited set of formatting tags such as <b>....</b> for bold and <i>...</i> for italics. So I used bold text to set off the fact names such as Birth:. I also experimented with a number of fonts to see which one I thought looked the best. In general, I don't like the old standby of Times Roman all that much because I think it's pretty boring. But I was surprised to discover that the bolding effect looked better in Times Roman than in any of the other fonts I tried.
4. Since I was going for a very terse sentence structure, I had to use [Date:Plain] and [Place:Plain] to get rid of the prepositions instead of using just [Date] and [Place].
5. My project to move Place Details back into Place is still ongoing, so I had to include [PlaceDetails] in the templates. I will remove [PlaceDetails] from my templates after I have removed all Place Details from my database.

I did make one other change in my strategy of using bold fonts. For years (decades, really) I have used bold fonts for last names in all my notes. I found that having bold fonts for fact names and also bold fonts for last names made for a very cluttered look. So I removed all the bolding from my notes. I hated to do it in a way, but it was for the greater good.

 

Just as an FYI, here's another sample sentence template. Like all the other ones except for the Birth template, it's very simple, really, since it doesn't have to worry about creating a new line.

<b>Burial:</b> <[Date:Plain],>< [PlaceDetails]>< [Place:Plain]>.

Jerry

[TomH]

 is there a complete list of phrases somewhere that can be used to make the template, such as the <[date]> etc... or is it a try to find it as you need it thing at this point?

Bill Bienia's RootsMagic 4 Tip Sheets is still pretty complete and accurate: http://support.roots...ic-4-Tips-Sheet (use the 2nd or 3rd URL).

[texas_nightowl]

Somehow I missed this for a while but I just checked it out and I think I like it! I may have to finally figure out how to use Tom's SQL tools! The report is very readable and looks great

[Jerry Bryan]

A sad little problem about this way of doing narrative reports did not occur to me until later. I reported the problem in other threads on this forum, but let me duplicate that report here for completeness of this thread.

 

A GEDCOM export and import (and hence also a drag and drop) does not maintain the sentence templates that I use to create point form reports. That's because most of the facts involved are built-in facts types and a GEDCOM export/import does not maintain customization of the default sentence templates for the built-in facts types. Even File->Import Lists... does not import default sentence template customizations for the built in fact types.

 

I sort of understand the export/import not importing default sentence template customizations for the built in fact types. But I guess I don't understand why File->Import Lists... does not import default sentence template customizations for the built in fact types. That would seem to me to be the whole point of importing a fact list from another database. I could get around this problem pretty easily if I had to by using SQLite. But I don't think SQLite should be necessary.

 

Jerry

[Jerry Bryan]

I ran into an odd problem with one of my point form sentence templates just now. I was getting a line of text that said simply they. It turns out that it was for a marriage fact for a couple who married, divorced, and married a second time. My sentence template for the principle role for the marriage fact was 

<b>[Couple]</b>
<<b>Marriage:</b> <[Date:Plain]><,< [PlaceDetails]>< [Place:Plain]>>.>

I needed to change it to

<b>[Couple:full]</b>
<<b>Marriage:</b> <[Date:Plain]><,< [PlaceDetails]>< [Place:Plain]>>.>

Without the :full option, RM was converting names to pronouns on the second occurrence of the marriage fact, and the pronoun for a couple is they. I guess it had never even occurred to me that the :full option could be used with [couple], but it can. It's just that the :full option seldom comes into play with [couple] because there are seldom very many couple type facts in a row for the same couple. It seems to require three of them in a row to get the they pronoun to be used with [Couple] without the :full.

 

The second marriage for the same couple is not a common situation, but I have several of them in my database. I even have one case where their is a third marriage of the same couple. I am considering customizing the sentence template for the specific marriage fact for the second or third marriages to something like the following, but I'm not sure if I'm going to make the additional customization or not.

<b>[Couple:full]</b>
<<b>Remarriage:</b> <[Date:Plain]><,< [PlaceDetails]>< [Place:Plain]>>.>

Jerry

 

 

P.S. There was another odd situation associated with diagnosing this problem. To start with, I didn't really understand what was causing the problem and I couldn't even figure out which fact was causing the they pronoun to be produced. So I started marking some of the marriage/divorce/marriage sequence of facts as private to take them out of the report temporarily to see which fact was causing the they to print. But when I did that, it caused the they to disappear from the report no matter which of the marriage/divorce/marriage facts I left in. That's because I was reducing the number of marriage/divorce/marriage facts in a row below the threshold which caused the they pronoun to be printed.

 

Jerry

[TomH]

I wonder if replacing [couple] with "[person] and [spouse]" might work as a default sentence and not warrant local customization.

Or even:
Married: [spouse]...

[Jerry Bryan]

I wonder if replacing [couple] with "[person] and [spouse]" might work as a default sentence and not warrant local customization.

Or even:
Married: [spouse]...

 

Armed with your suggestion, I decided to go with the following for now.

<<b>Marriage:</b> <[Date:Plain]><,< [PlaceDetails]>< [Place:Plain]>>.>, [Couple:full]

<<b>Divorce:</b> <[Date:Plain]><,< [PlaceDetails]>< [Place:Plain]>>.>, [Couple:full]

Moving the date to the front is more consistent with the other facts. [Couple:full] takes care of the they problem. No individual fact customization is required unless I want to consider Remarriage instead of Marriage on a second or third marriage to the same person. But I think I'm going to leave the second and third marriages as Marriage rather than as Remarriage.

 

Your suggestion to replace [Couple:full] with [Spouse:full] is definitely interesting. (I wouldn't want just [Spouse] for fear of getting a pronoun.) Indeed, I share the standard marriage fact with the principles to the marriage to get the marriage to appear in timeline order in addition to appearing in the family section of the report. My sentence template when I share a marriage fact with the principles to the marriage is as follows.

<b>Marriage:</b> <[Date:Plain],><< [PlaceDetails]>< [Place:Plain],>>< age [ThisPerson:Age:plain],> to <%[Wife]|[Husband]>.

Maybe this one would work well also for the standard unshared marriage fact, except that I can see that maybe I need <%[Wife:full]|[Husband:full]>, and maybe I could get by with to [Spouse:full] instead of having to have the gender switch. In fact, the gender switch could be problem in the case of same sex marriages. I don't yet have any same sex marriages in my database, but I suspect that eventually I will.

 

So this is what I decided to go with for the unshared version of the facts. In the unshared version, you have to use Person rather than ThisPerson. The ThisPerson construct only applies to shared facts.

<b>Marriage:</b> <[Date:Plain],><< [PlaceDetails]>< [Place:Plain],>>< age [Person:Age:plain],> to [Spouse:full].

<b>Divorce:</b> <[Date:Plain],><< [PlaceDetails]>< [Place:Plain],>>< age [Person:Age:plain],> from [Spouse:full].

Much thanks for the ideas.

 

Jerry

[Cmin]

I've transferred my genealogy data from Rootsmagic descendant narrative report to Microsoft Word and am editing the report. As I add additional info such as documents, photos, additional text--my index is no longer correct. Can I make a new index in Microsoft Word easily? Thanks Carol 

[Jerry Bryan]

I've transferred my genealogy data from Rootsmagic descendant narrative report to Microsoft Word and am editing the report. As I add additional info such as documents, photos, additional text--my index is no longer correct. Can I make a new index in Microsoft Word easily? Thanks Carol 

 

Yes. Highlight the index and click F9.

 

Jerry

[Jerry Bryan]

I have been playing around with creating Web pages using my point form sentence templates. For the most part, the point form sentence templates produce very nice results when making Web pages. These are the pre-RM6 Web pages where you can make Web pages that look like descendant narrative reports (and also that look like Family Group Sheets and a few other useful things). But I have run into one little glitch.

 

The glitch is that when making Web pages, RM's Web page maker does not honor carriage returns in the sentence templates by producing a new line on the Web page. The required HTML tag would be <br /> every time there is a carriage return in the sentence template. For the most part, this doesn't matter because I force facts to begin printing on a new line, not with a carriage return in the sentence template, but rather with a carriage return as the last character in the fact note for the immediately preceding fact.  The only time I use a carriage return in a sentence template is for the birth fact, where my point form template is as follows.

[Person:Full].
<b>Birth:</b>< [Desc]>< [Date:Plain]><,< [PlaceDetails]>< [Place:Plain]>>.

This sentence template causes the person's name to print on one line and their birth date to print on the next line. It works fine for printed reports but not when making Web pages. When making Web pages, the birth information goes on the same line as the name which destroys the look and feel of the point form report.

 

A solution would be to create a dummy fact of some kind in front of every birth fact to cause the name to be output. The birth information itself would then go on the next line as desired provided only that the dummy fact's note was terminated with a carriage return.

 

I use a totally manual procedure to make the changes to sentence templates to produce point form reports. One version of Tom's automated SQLite procedure to do the same thing used a dummy fact such as I'm describing, but his current version does not have a dummy fact in front of the birth fact and Tom's birth fact has a sentence template that looks very similar to mine.

 

I'm still considering how best to address this problem. In my considerations, I'm mindful that the pre-RM6 Web pages have been deprecated and therefore are unlikely to be supported in the RM rewrite. If there is not something roughly equivalent to the  pre-RM6 Web ages in the RM rewrite, I may resort to exporting GEDCOM from RM8 back to a copy of RM7, just to be able to produce acceptable Web pages. But that would still leave me with the question of how best to get the birth information onto a new line in the Web page version of a Descendant Narrative report.

 

By the way, using Microsoft Word to do a File->Save As of an RTF file produced by RM to an HTML file is not really a very acceptable alternative. That's because such an HTML file would look just fine but it wouldn't have all the user friendly hyperlinks that the current pre-RM6 Web pages support.

 

Jerry

 

[draydev1]

Hi, Jerry.

I just found this post, and this report is exactly what I am looking for.  Thank you so much for sharing it!

Because I can be a perfectionist, I haven't gotten really far in entering data into my software, yet.  (Don't be fooled, I have a ton of research documents, just not entered yet) My problem is self-sabatoge because I'm too busy looking at the boards and YouTube and trying everything, but then not liking how the reports print. This leads to trying something different, and so on.

I thought about entering the facts and sourcing them but putting all notes into the Person Note to make a mini biography, plus i could make the sentences sound the way I want.  Each note would have the bold headers like in your report (to know which fact they correspond to) but I didn't like that there is no source superscripts with the notes, and it all just didn't work as I envisioned it.  I've even saved reports as .rtf files and tried revising but I basically was completely retyping the entire report. I know the database won't do all the work and I don't want it to but I still couldn't find the type of report I wanted.  Until now!!

I think I understand how you created the sentence templates for the facts.  They don't seem too difficult.  While I have 37 people entered in the database, I honestly don't have much information entered for each one.  Would it be better to create the new facts and basically start a new database (it will help me start fresh and I really don't mind that since I've changed my mind so many times; it will help me clean up everything). Or should I go into each person, go into each individual fact I used for them and change each fact sentence? Then, create the new facts and use those for all new information entered?  I'm leaning toward starting over. 

 

I wouldn't really be creating too many new facts and Gedcom is not much of a concern to me, although, from what I'm reading, they may still transfer just fine.  What to do, what to do?

 

Thanks for any help.

 

Kim

[Jerry Bryan]

From what you have said, it sounds like what you need to do is to keep your existing database and basically leave your facts for each person as they are. The changes you need to make are in Lists->Fact Type List. For example, consider the death fact. Change the sentence template for the death fact to something like the following.

<b>Death</b>: <[Desc]>< [Date:Plain]>< [person:Age:plain:commas]>< [PlaceDetails]>< [Place:plain]>.

This will change the sentence for every death fact in your entire database, all at one go. You may want to change the template a little bit as compared to mine to meet your own needs. Preceding the "Death:" text in the template with <b> and following it in the template with </b> has the effect of making it print in bold in reports. It may or may not  be obvious just from looking at my template, but it begins with a carriage return to force the death fact to a new line. This is the sort of thing that you might or might not want to do in your own reports.

 

Make similar changes to other fact types such as birth, marriage, burial, etc. that you will find  under Lists->Fact Type List. The trickiest fact is probably the birth fact because it serves double duty as identifying the person's name and also giving their birth date. My current template for the birth fact is as follows. It is the only one of my templates that does not begin with a carriage return because a new person begins on a new line anyway.

[Person:Full].
<b>Birth:</b> <[Date:Plain]>< ,[Place:Plain]>.

Jerry

 

 

P.S. I'm no longer using Place Details in my database because they export so poorly to software other than RM. Instead, I combine the data that would go into Place Details into the field called Place. I see that I have removed the Place Details variable from my birth template but have not yet done so from my death template. There is no harm in my death template because nothing prints from the Place Details variable if there is no Place Details data. But it's something I should clean up eventually. Your mileage may vary in this and other respects, depending on whether you use Place Details and on other ways in which you may enter your data.

[draydev1]

Thank you Jerry.

 

I did see where the <b> and </b> caused the bold type, and I actually like that in the report.  I didn't realize the carriage return so I will probably add that. Do you know if the carriage return affects the Narrative report (NEHGS) when you have the three options of "keep fact sentences in same paragraph", "new paragraph after every fact", or "new paragraph after facts with notes"?  I can just play with it to see.  Just wondered if there was one you use over the others.  Right now I have "new paragraph after every fact" and it's awful, but that's because of the standard fact sentences.  It might work pretty well when I change the sentences and add notes into the fact notes.

 

I was thinking it was better to create new facts because I didn't want to lose the default sentence templates. However, changing them at the same time using Lists->Fact Type List means I can just as easily go back and change them back to the default if I choose.

 

I do have a couple other questions about some of your sentences.  Just want to make sure I understand them.  You have a few that are just the bold title: then your note. For example:  Namesake: (after the Birth info for Sallie Jane Cole) and Gravemarker: (after the Burial for Sallie J. Peters).  Are those facts with just the <b>Namesake:</b> with date and place empty or did you just put those titles in the fact notes for Birth and Burial?  I can see where that may easiest to do (putting them in the notes) instead of creating a new fact for them.  (I actually just tried putting them in the note for the fact and it works like a charm! I just opened a fact note, did a carriage return to start the note under the fact sentence, typed Namesake: and a generic note, then looked at a report. It worked perfectly!)

 

So glad I have tomorrow off from work.  Got some more work to do on this database.  Thank you again!!

 

Kim