28 replies to this topic

[texas_nightowl]

I'm a little torn on _Heading vs Birth fact sentence. On the one hand, Having the _heading in the person facts seemed a little weird to start. And I'm still not sure what I think about it. On the other hand, I know along the line that I do have some spouses, etc. for whom I don't (yet?) have birth facts. Ideally I will get those addressed, but is it better to have a blank birth fact or the _heading fact? I'm not sure.

 

For the moment, I will run the v1 Restore and then the v2 Setup and see how things look! Thanks so much! (P.S. was my edit with the RMNOCASE instructions/links ok?)

[Jerry Bryan]

A curious asymmetry I came across is that the Report Preview is satisfied by 0x0A to output a line feed and carriage return but not 0x0D while the Note Editor is the opposite. I found it necessary to append both control codes to the Note so that the new line was not stripped by one or the other process.

 

The hexadecimal sequence 0D0A (carriage return followed by line feed) is the Windows convention (inherited from DOS) for terminating lines in text files. By contrast, the UNIX convention for terminating lines in text files is a bare hexadecimal 0A (line feed). These differing conventions have caused problems for decades in exchanging text files between UNIX and DOS/Windows.

 

A carriage return without a linefeed in DOS/Windows or a linefeed without a carriage return in DOS/Windows usually produces highly unpredictable results. So I'm not surprised that a bare carriage return and a bare linefeed created problems when Tom tried them.  When I have looked inside notes in RM with SQLite, I have always seen lines terminated with a complete 0D0A sequence (carriage return followed by line feed), and I'm sure that's the only safe way to go.

 

Jerry

[texas_nightowl]

Your problems with white space with marriage type facts etc. are getting into issues that exist whether you are using point form sentence templates or not.

 

For example, suppose you place white space controls into the default sentence template for a certain fact type (or types). ...

 

 

Oh, I definitely appreciate that the reports will take more manual work. But what I love about this Point Form style is that even with single spacing, it appears neat and easily readable to me. With default sentences, I always felt like I needed a blank line between facts because everything just took on a run-on appearance.  So with this Point Form style, I am actually happy with single spacing. (In terms of Tom's script, I selected spacing "1".) The only place where I therefore felt that extra spacing help was required was around the family facts.

 

Given that I like this layout so much, and with Tom's change to add carriage returns to the last family fact note, I now *don't* need to place any white space controls in sentence templates or notes!

 

Oh, there will still be edits...the ,: to . change for the "spouse, son/daughter of x and y" for example. And there will be the odd "exceptions" to the rule. But I am really happy with how this style looks! So for me...it is nearly camera ready.

 

In the sample document you posted to the original thread, I did spot something I liked, but I'm fairly certain it was a manual edit. At the start of the family section, you had the "groom and bride" in bold and then the marriage/family facts followed. Am I right that that was manual editing?

 

 

 

Tom...I did run the v1 restore and v2 setup and at quick glance, it all looks great!  One clarification though...it is best to run this only when ready to generate the report, correct? And then run the restore after? Though alternately I suppose I could leave it, ie. not run the restore, and for any new marriage facts entered, just add the line returns and {CR} manually? But in terms of keeping things the "same" and not having a miss-match, I think I might prefer doing a run then restore whenever I needed to generate the narrative. Your opinion?

[TomH]

In the sample document you posted to the original thread, I did spot something I liked, but I'm fairly certain it was a manual edit. At the start of the family section, you had the "groom and bride" in bold and then the marriage/family facts followed. Am I right that that was manual editing?

I cannot find that sample.  
 

One clarification though...it is best to run this only when ready to generate the report, correct? And then run the restore after? Though alternately I suppose I could leave it, ie. not run the restore, and for any new marriage facts entered, just add the line returns and {CR} manually? But in terms of keeping things the "same" and not having a miss-match, I think I might prefer doing a run then restore whenever I needed to generate the narrative. Your opinion?

That's a difficult question to answer. Eventually, RootsMagic upgrades will render the script obsolete, if not unusable. If RootsMagic has not by that time implemented a similar style, then you have lost the Point Form Narrative style should you always restore from it.

 

Should you commit your database to Point Form Narrative, then you have to maintain the style yourself, keeping in mind its rules or conventions for consistency whenever you edit or transfer between databases. That would be like a one shot conversion to a state similar to Jerry's database for which he maintains the style manually (mainly). The script leaves 5 tables in the database for the Restore After function which will become increasingly erroneous as the database is edited so they should be dropped from the database (as the Restore script does).

 

The Restore After script was developed so that one could play with the many possible combinations of RootsMagic's report format settings with the Point Form Narrative script's format settings. Perhaps one additional script to commit the database to the PFN style (i.e., drop the restore tables) would be desirable for users who know next to nothing about SQLite.

[Jerry Bryan]

Another possibility than restore would be always to make a copy of the database and to run Tom's script in the copy immediately before running the report from the copy. That way, you would never have to run a restore and your real database would never be changed by Tom's script. Essentially, you would be creating a reporting database, and you would be recreating the reporting database every time you run a report.

 

Since I didn't have Tom's script available to me at the time, I did everything manually and my database is fully committed to the point form style. It would be a lot of work for me to change back. But Tom is correct that at some point his script will be obsoleted by changes in RM itself.

 

The sample report was mine. I'll have to research how I handled the bride and groom information in the family section, whether it was a manual edit or whether it was something I was able to automate.

 

One thing that you might or might not have noticed is that marriages appeared in both the individual section and in the family section. This is a trick that I came up with that has nothing to do with point form style. I basically don't use RM's shared facts because they don't export in GEDCOM to third party software and because I have discovered that they don't actually save me any editing time. But I have made an exception for marriage and divorce facts. Shared facts print out in the individual section of the report instead of in the family section of the report. Therefore, if you share a marriage or divorce fact with the spouses themselves, their marriages will appear in timeline order in the individual section of the report. Showing marriages and divorces and other so-called family facts in timeline order is a much wished for feature for RM that has never been provided. But you can provide it yourself if you wish by using this trick. If you do, be aware that the shared version of the fact can have different sentence template and a different fact note than the original fact that is being shared. I take advantage of the different fact note to provide proper white space for the marriage and divorce when they appear in the individual section of the report.

 

Jerry

 

[texas_nightowl]

Another possibility than restore would be always to make a copy of the database and to run Tom's script in the copy immediately before running the report from the copy. That way, you would never have to run a restore and your real database would never be changed by Tom's script. Essentially, you would be creating a reporting database, and you would be recreating the reporting database every time you run a report.

 

Yes, you are right. That is what I get for trying to think about this after midnight. It does make sense to simply make a copy and run the script and then generate the narrative report and then delete the "reporting" database.

 

All I really have to do is keep my main database in order...which thanks to Tom's script is practically nothing! Yay!

 

Of course, no idea how things will change when RM 8 appears with all the rewrites.

 

 

 

One thing that you might or might not have noticed is that marriages appeared in both the individual section and in the family section. This is a trick that I came up with that has nothing to do with point form style. I basically don't use RM's shared facts because they don't export in GEDCOM to third party software and because I have discovered that they don't actually save me any editing time. But I have made an exception for marriage and divorce facts. Shared facts print out in the individual section of the report instead of in the family section of the report. Therefore, if you share a marriage or divorce fact with the spouses themselves, their marriages will appear in timeline order in the individual section of the report. Showing marriages and divorces and other so-called family facts in timeline order is a much wished for feature for RM that has never been provided. But you can provide it yourself if you wish by using this trick. If you do, be aware that the shared version of the fact can have different sentence template and a different fact note than the original fact that is being shared. I take advantage of the different fact note to provide proper white space for the marriage and divorce when they appear in the individual section of the report.

 

I did notice that and I will likely follow your lead. I have never shared any other facts because of the gedcom export issue. But I may make an exception here. I like seeing the marriage facts under the individuals.

 

I really have started to hate the mention of "GEDCOM". It used to matter to me because my dad was still on FTM and we share data. I spent a lot of time procrastinating on how to do sources because of the terrible exports when using templates. (I basically use freeform though I sometimes add an extra details field or two. I am a moderate lumper/splitter? I do my census sources on a county level. Other things I lump when possible but still come close to EE standard. Finally bought EE last fall.)  Anyway, now my dad is on RM, so yay! But...drag and drop is still using gedcom underneath.  And...I have also started a blog/website and I don't "love" the website files that RM generates. So my options are to either: use the Roots Persona wordpress plugin (uses gedcom), use TNG (The Next Generation of Site Building; uses gedcom), or transfer to Legacy and generate pages from Legacy (uses gedcom). So, I really get tired of always thinking about gedcom!

[Jerry Bryan]

 

I did notice that and I will likely follow your lead. I have never shared any other facts because of the gedcom export issue. But I may make an exception here. I like seeing the marriage facts under the individuals.

 

Just to beat a dead horse here, I decided to treat the loss of shared marriage facts in a GEDCOM export as just a formatting issue with no loss of real genealogical data. After all, the real marriage facts are still there as unshared facts for the couple.

 

Jerry

[TomH]

Just to beat a dead horse here, I decided to treat the loss of shared marriage facts in a GEDCOM export as just a formatting issue with no loss of real genealogical data. After all, the real marriage facts are still there as unshared facts for the couple.
 
Jerry

True. But the real loss is the history for roles other than bride and groom. Likewise for many sharers of other events.

[Jerry Bryan]

In the sample document you posted to the original thread, I did spot something I liked, but I'm fairly certain it was a manual edit. At the start of the family section, you had the "groom and bride" in bold and then the marriage/family facts followed. Am I right that that was manual editing?

 

Sorry that I never got back to you on this. It was a customization in the sentence template. No manual editing was required.

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

Jerry