Jump to content


Photo

Try a Point Form Narrative - a SQLite script makes it easy!

narrative sqlite

  • Please log in to reply
28 replies to this topic

#1 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6145 posts

Posted 02 February 2016 - 07:48 AM

Point Form Narrative? Sounds like an oxymoron. But maybe it makes a lot of sense. Jerry Bryan showed a highly praised example of this quasi-hybrid of an Individual Summary and Descendant Narrative in the discussion  "Preparing an RM Descendant Narrative Report for a Family Reunion for This Year". He developed it with largely manual editing of sentence templates. I liked the concept so much that I spent too many waking hours developing SQLite scripts with which the conventional full sentence templates are replaced with point form sentence templates. Thus a database can be set up for such a report in seconds and another script restores sentences to their prior state so that it is possible to quickly toggle back and forth while tweaking both script format settings and RootsMagic report settings.

 

Full story and scripts are available at Reports - Point Form Narratives Setup.

 

Please try it out and let us know what you think of Point Form Narratives with your database. 


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#2 mleroux

mleroux

    Advanced Member

  • Members
  • PipPipPip
  • 68 posts

Posted 11 February 2016 - 11:03 AM

Tom, I can't believe no one has commented on this before. Many thanks for doing this. I, at least, love it and plan to use this format.

 

Thanks


Marc
Always learning and loving the discovery process. Focusing on the Huntingdon and Soulanges areas of Quebec - O'Connor/Leroux/Walsh/McCann/Savage/Lalonde/Lauzon


#3 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6145 posts

Posted 11 February 2016 - 12:46 PM

Thanks for the feedback.

 

It does seem counterintuitive for people to struggle for years to make better composed narratives directly from the database only to throw that out in favour of point form style. Therefore it won't appeal to necessarily many of those who have viewed these discussions and only a subset of those will be comfortable or dare to use SQLite to modify their database.


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#4 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3402 posts

Posted 11 February 2016 - 02:13 PM

As Tom mentioned, I developed a point form narrative for myself totally manually, simply by changing the sentence templates for the 15 or 20 fact types that I most commonly use. Tom's efforts are much more ambitious, using an automated process to change the sentence templates for all the fact types in your RM database, and then allowing you an easy way to change back. Tom's efforts bring up an interesting point that might be pertinent at this time, especially since the total rewrite for RM is said to include a significant revamping of RM's report engine.

 

The interesting point is that your RM database only includes a single sentence template for each of your fact types. Suppose you wanted to run standard narrative reports on Mondays, Wednesdays, and Fridays and suppose you wanted to run point form narrative reports on Tuesdays and Thursdays. And further suppose that for whatever reason, you didn't want to run Tom's SQLite script to switch back and back and forth. Under these circumstances, you only recourse would be to spend a lot of time each morning manually editing a bunch of sentence templates to switch between your Monday/Wednesday/Friday style of sentence templates and your Tuesday/Thursday style of sentence templates.

 

I think instead that RM should support multiple sets of sentence templates. In practice, this would probably mean having multiple copies of RM's FactTypeTable, with each copy of the FactTypeTable implementing a particular report style. And these multiple copies of RM's FactTypeTable should be exposed to the user interface so the user could easily choose standard style or point form style. But why stop at two styles. Why not have a verbose style and a terse style and a German style and a Spanish style, etc. in addition to the standard and point form styles. And why not arrange things so that users could exchange report styles that they might have developed. I would point out in this regard that RM's present design doesn't even allow you to Drag and Drop a copy of your database to yourself while maintaining any customizations you have made to the built-in sentence templates in the FactTypeTable. So today, you can't even carry over a report style that you develop to another copy of your database that you make with Drag and Drop.

 

Finally, RM's FactTypeTable is not just about sentence templates. It's also about which fact types are included in which kinds of reports (GEDCOM export, narrative reports, family group sheets, etc.), it's about which fact types have dates or descriptions or places, etc. These attributes of the FactTypeTable would also benefit greatly from having multiple styles with the styles being exposed to the user interface. For example, one style might export one list of facts in GEDCOM and another style might export a different list of facts in GEDCOM. At the present time, adjusting the list of fact types to be exported to suit your intended audience is a very major pain.

 

I'm sure I have written about multiple report styles before. But given the rewrite of RM's report engine and given Tom's really wonderful SQLite script to automate the process of producing point form reports, I think it's a good time to bring up once again the idea of RM supporting different styles for the FactTypeTable.

 

If you haven't looked at any point form reports, I think they look pretty nice - even if I do say so myself. They are not just individual summaries or family group sheets stuffed into the format of a narrative report. Indeed, they can contain a great deal of narrative if you have a lot of information included in notes, despite how terse the presentation is for the basic facts. I posted an example of a real report done in this style in my original posting on this subject which in turn was cited by Tom. I'm sure that the point form report style will not be for everybody, but if you wish you can see an example of such a report without having to create one for yourself.

 

Jerry



#5 FHckr

FHckr

    New Member

  • Members
  • Pip
  • 1 posts

Posted 02 April 2016 - 03:03 PM

Hi! I am a newbie to the forum, and hope it is okay to post a comment and ask a question amongst all you Advanced Members :unsure:

First I'd like to say how much I like the clean look of your Point Form Narrative report, Jerry. It is concise, easy to read, and easy to understand! Second, I have noticed and I am impressed by the dedication that drives you Advanced Members to go to such great lengths to tweak and personalize the end-results/output style generated by the RM7 software. Thank you Jerry and TomH for the countless hours you spend and for your willingness to share so others can learn from your experience. Here is my question: is it possible for someone with only a very basic exposure to programming to create a Point Form Narrative report running RM7 on a Mac?

 

Since I prefer to spend my time researching and I writing, I hope this style of report will be a user option in the new Roots Magic 8 for both PC and Mac.

 

Thanks, in advance to any help you can give me. 

 

Liz



#6 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3402 posts

Posted 02 April 2016 - 06:59 PM

Here is my question: is it possible for someone with only a very basic exposure to programming to create a Point Form Narrative report running RM7 on a Mac?

 

On a PC, I would suggest that there are two things you can do. You can run Tom's script, or you can edit of the sentence templates yourself. I did the latter and I only had to edit something like 10 or 15 or 20 fact types because those are the only ones I use. I'm not really sure which technique would be easier for a new RM user. Both techniques require a minor bit of what you might call "programming skills". I guess it depends on whether a very basic exposure to programming is enough or not.

 

But I would probably suggest starting with editing one or two sentence templates yourself, and see if you like the results and if you feel like you can handle the editing of the sentence templates. There are sample templates in some of the previous posts about point form templates, and you can just copy and paste them from these forums into RM. Well, let me just repost a couple of them. These templates are for the principal role, not for the witness role. You get into the templates by doing Lists->Fact Type List...

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

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

To run Tom's script, you need an SQLite manager. I'm familiar with a couple of SQLite managers for the PC, but I'm not a Mac person. I assume SQLite managers surely exist for a Mac, but I don't know anything about which ones might exist or how they work.

 

If you choose the manual editing route, manual editing of sentence templates works exactly the same for RM on a Mac as it does for RM on a PC.

 

Jerry



#7 texas_nightowl

texas_nightowl

    Advanced Member

  • Members
  • PipPipPip
  • 79 posts

Posted 05 April 2016 - 02:55 AM

Hey Tom - as per my post in Jerry's original thread, I was tempted enough by this Point Form Narrative to actually install SQLite Expert Personal and give this a try. At first I got an error about the RMNOCASE collation (might I suggest adding a link to the unifuzz.dll page after the sentence about needing collation? I had no idea what that meant.).

 

In any case, things went well and I have now generated a narrative report to review.  I do have a couple questions. First, here is a screenshot to illustrate. 

 

9izct6V.jpg

 

Question 1: Is it possible to start the "Marriage" fact sentence on a new line instead of in a paragraph with the "Marriage License" fact?

 

Question 2: Is it possible to put the spouse in a new paragraph? ie. separated with a blank line from the marriage facts?

 

Question 3: any idea why I have a comma then a colon at the end of the spouse sentence? Where can I look to figure out why it is doing that?

 

Basically, I would like to see:

 

Marriage License: blah, blah, blah

Marriage: blah, blah, blah

 

Spouse Name, daughter of x and y:

 

How do I get there? Can I get there?



#8 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3402 posts

Posted 05 April 2016 - 07:57 AM

For question 1 and 2, yes it is possible, but the process is not very clean. I manage white space such as this by appending a carriage return to the fact  note for the previous fact. I've been doing the "carriage return at the end of notes" thing for years, so I didn't have to do anything special when I switched my sentence templates to point form. Long after I started doing the "carriage return at the end of notes" thing, RM introduced a new option to start new facts on a new line. I investigated the new option seriously, but I decided to stay with my old way of doing things. The RM feature is unconditional - which is to say, it's all or nothing. With my way of doing it, I can specify which cases I want a new line and which cases I don't. I think Tom developed an SQLIte procedure that will insert the needed carriage returns, but his procedure is also unconditional (of necessity). If you want to go that route and if you want the carriage returns most of the time time, you might run his procedure and remove the carriage returns you don't want.

 

RM's GEDCOM export has a bug in that it omits the trailing carriage returns. My bypass for this bug was to add a dummy private note after the carriage return - a dummy note enclosed in squiggly braces.

 

If you force a new line as described here, the next line will start with a blank and it really shouldn't. I regard this is a bug in RM, but the RM folks might argue that it's not a bug because I'm using RM in a way that's not intended. I get around this problem by storing all my reports as RTF files and editing them with a script that removes the spaces at the beginning of lines that shouldn't be there. The trick is to do a global replace of the string \vertaltbb with the string \vertaltb. I'm using b with a dash in it to indicate a blank character. \vertalt is the tag in RTF files to go to a new line and you have to remove the extra space that shouldn't be there. This doesn't take very long if you do a global replace.

 

For question 3, I'm not sure where your colon is coming from. I get a similar problem myself, but my problem is a comma immediately followed by a period. This is a consequence of the fact that the spouse sentence is generated by RM without using a sentence template. Or maybe the spouse sentence is generated using a sentence template that's strictly internal to RM. In any case, you as the user do not have access to the sentence template. So I fix my problem by replacing all occurrences of ,. in the RTF with just a period. I can do this either in the text editor or in Microsoft Word itself. The \vertalt thing has to be done in a text editor.

 

Both the NGSQ report and the NEHGS report produces a list of the children immediately after the listing of the couple. This list includes only the basic BMD facts for the childre. Generally speaking, the children appear again in the next generation in their own right if they marry or have children. But the short list of children is produced without using sentence templates, so you have no control over the list. I have chosen to accept this problem for now and my summary sentences for the children are not in point form. When the children appear again in the next generation in their own right, their sentences are indeed in point form.

 

The problem of RM producing parts of the report without using sentence templates has negative consequences that go far beyond the production of point form reports. For example, if you want to produce a report in a language other than English you can change the sentence templates to the language of your choice. But having done so, any sentences produced without using sentence templates will still be in English. RM's report generator is being rewritten in the overall rewrite of RM that is underway. One of the most critical items for the report generator is that it able to generate reports in such a way that every single bit of the report is under the control of sentence templates that in turn are under control of the user and exposed to the user interface.

 

Jerry

 



#9 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3402 posts

Posted 05 April 2016 - 08:03 AM

One more thing on the white space issue. The sentence templates themselves can include white space characters such as carriage returns. You might find that to be a cleaner way to get the spacing you want and doing it in the sentence templates does not produce the extra space at the beginning of lines. I have decided not to switch my carriage returns from the notes to the sentence templates for now, but I might switch going forward. The nice thing about the way I'm doing it now is that the carriage returns do export in GEDCOM (well, they do after adding dummy private notes to them) so they are exported to third party programs. Carriage returns in sentence templates do not export in GEDCOM. But I have to keep reminding myself that things like formatting and white space are just metadata and do not represent the real genealogical data. So moving the carriage returns to the sentence template might really be the best way to go.

 

Jerry



#10 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3402 posts

Posted 05 April 2016 - 08:13 AM

But I have to keep reminding myself that things like formatting and white space are just metadata and do not represent the real genealogical data.

 

I know I'm in trouble and just need to shut up when I start quoting myself. But on the other hand, I do have to keep reminding myself that formatting is important  even if it's only metadata. For example, one of the biggest heartburns that TMG users have in switching to RM or in switching to any other software than TMG is the loss of formatting of their reports - split memos and things of that sort. TMG has a richer sentence template language than RM, and it has a richer set of relationships and roles for shared facts than RM. And TMG's richer sentence template language is closely tied to its richer set of relationships because it is those very relationships that can be expressed in the sentence template language. But shared facts and sentence templates are some of the things that that export least well from one genealogy software to another. So on the other, other hand, I have to keep reminding myself that for users such as me who are very worried about the portability of their data, we shouldn't use features such as shared facts. So what to do?

 

I don't know, but I do know that if ever RM went out of business and I had to switch to something else, I want to get all my "real data" into the new system and I would expect to have to redo all my sentence template and formatting stuff from scratch. That's just the way it is.

 

Jerry



#11 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6145 posts

Posted 05 April 2016 - 11:24 AM

 
Question 1: Is it possible to start the "Marriage" fact sentence on a new line instead of in a paragraph with the "Marriage License" fact?
 
Question 2: Is it possible to put the spouse in a new paragraph? ie. separated with a blank line from the marriage facts?
 
Question 3: any idea why I have a comma then a colon at the end of the spouse sentence? Where can I look to figure out why it is doing that?

1. Yes. You could edit the sentence for Marriage to have leading carriage return(s). However, that may need to be done local to those persons having a couple event sorted before Marriage because I think RM automatically starts a new paragraph on the first couple event. If you edited the default sentence for Marriage to have the leading <CR>s then you will have excessive white space ahead of the Marriage paragraph for persons having that as their first event with a given spouse. The script prepends the CR to all events except Marriage - that exception can be easily removed but it is another matter to do so on condition that there is an earlier event for the same couple. I'm sure it is possible.

2. Yes, as Jerry and Kevin have suggested, by appending a CR or two (or markers for global search and replace after saving to RTF) to the Note of the Marriage event. That assumes that RM always outputs the spouse name immediately after the Marriage event. What about couples who have no Marriage event? Adding the CRs to all Marriage events should be easy programming.

3. I don't know why or that there is anything you can do about it.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#12 texas_nightowl

texas_nightowl

    Advanced Member

  • Members
  • PipPipPip
  • 79 posts

Posted 05 April 2016 - 12:38 PM

Thanks Jerry and Tom...just have a second now but will read thoroughly again later. I will play with adding carriage returns. I will see if I can successfully add a carriage return to the *end* of the "Marriage License" fact sentence. And then I will try to do the same to the "Marriage" fact sentence except to make it 2 lines. Depending on success, will add lines to the "Marriage" fact note. I really want the spouse to start in his/her own paragraph.  I really don't need new lines in any other facts. With this point form, I like the way things display except for this family section.  And I really really hope RM drops the hidden sentence templates in the rewrite. Really....why do I have a comma colon for the intro of the spouse?

 

Tom...on a side note, I "joined" your wiki last night. I was also trying the paragraph-strip (since I don't need extra lines any more except with family facts apparently!). I ran into one issue. Do you want me to edit the submit a problem page on your wiki or just throw it out here?



#13 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6145 posts

Posted 05 April 2016 - 01:13 PM

I'm conflicted as to where is better to post. Here usually results in a broader discussion that may unearth ideas that can be of value to others but I am wary of alienating those users who have no interest in the inner workings of RootsMagic. For a purely technical discussion, it is perhaps the considerate thing to post to the wiki.

 

You can post a message right on the wiki page in question now that you are a member, even edit the page, which allows you to highlight an area and tie a comment to it. I've seldom seen more than a two-way discussion on the wiki which makes me wonder whether anybody monitors it other than me.


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#14 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6145 posts

Posted 05 April 2016 - 03:00 PM

Question 3: any idea why I have a comma then a colon at the end of the spouse sentence? Where can I look to figure out why it is doing that?

I now know why. 

 

My script adds a custom Heading fact as the (hopefully) earliest sorted event with the sentence template: "[person]: ". This is to compensate for the collateral damage caused by removing the [person] variable from all other sentence templates in support of the less repetitious point form. In Narrative reports, RootsMagic bolds the [person] variable of the first event's sentence template to create its 'heading' for that person's section. If there is no [person] variable in the sentence, there is no bold name to act as a 'heading'. In response, I put the Heading fact in. 

 

That works fine for the beginning of the person's section but not for the spouse's subsection because RootsMagic takes the sentence template of the spouse's first individual event and inserts ", son|daughter of father and mother," right after "[person]". Now that the first sentence template is for my Heading event, you get the colon after the comma. The RM sentence modifier expects there to be at least one of Date, Description, Place or Place Detail to follow the comma; even if you use the default sentence and all these fields are empty, you end up with ",.". 

 

We cannot do anything to this hardcoded insertion. Because ",:" will be consistent for all spouses, it should be readily caught and easily cleaned up with global search and replace in MS Word editing of the RTF file. 


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#15 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3402 posts

Posted 05 April 2016 - 03:21 PM

My script adds a custom Heading fact as the (hopefully) earliest sorted event with the sentence template: "[person]: ". 

 

I have to be careful sometimes in posting about point form reports because I did mine manually instead of (actually before) Tom's script. So the way I did it may not correspond 100% with Tom's script and I forget that sometimes when I reply. For example, I retained the [person] variable as the first part of the sentence template for the birth fact and followed the [person] variable with a carriage return before getting into the birth information. Tom's solution for the placement of the [person] variable is much more elegant than mine, I think.

 

Jerry



#16 texas_nightowl

texas_nightowl

    Advanced Member

  • Members
  • PipPipPip
  • 79 posts

Posted 05 April 2016 - 04:20 PM

I'm conflicted as to where is better to post. Here usually results in a broader discussion that may unearth ideas that can be of value to others but I am wary of alienating those users who have no interest in the inner workings of RootsMagic. For a purely technical discussion, it is perhaps the considerate thing to post to the wiki.

 

You can post a message right on the wiki page in question now that you are a member, even edit the page, which allows you to highlight an area and tie a comment to it. I've seldom seen more than a two-way discussion on the wiki which makes me wonder whether anybody monitors it other than me.

 

OK, I have edited the Point Form Narrative page re: RMNOCASE collation. Basically added links to the 2 relevant pages and added an extra instruction step about loading the extension.

http://sqlitetoolsfo...arratives Setup

 

I will add a discussion or something to the paragraphing page shortly.

http://sqlitetoolsfo...om/Paragraphing



#17 texas_nightowl

texas_nightowl

    Advanced Member

  • Members
  • PipPipPip
  • 79 posts

Posted 05 April 2016 - 05:04 PM

If I am editing sentences correctly, it looks like that will not work when notes exist. I went to the Fact Type Lists and first edited the Marriage License "principal" role sentence to add 2 line feeds. That caused the Marriage License "note" to start after a blank line, not the next "Marriage" fact. So I retracted that back out.  Next I went back to the Fact Type Lists and edited the principal role for "Marriage" and added line feeds at the beginning of the sentence. This does give me the effect I want when there is both a License and a Marriage but does produce excessive/extra blank lines when no other family fact appears before marriage (as was mentioned above would happen). 

 

That said, it should be a fairly simple thing to look do a search and replace in the report in RTF format and where there are 3 blank lines, reduce to 2.

 

So that leaves just getting the spouse to start in a new paragraph and I suppose I am just going to have to have a line feed and a dummy private note or something to get that spacing.

 

Still playing.

 

Thanks for all the info above!



#18 texas_nightowl

texas_nightowl

    Advanced Member

  • Members
  • PipPipPip
  • 79 posts

Posted 05 April 2016 - 08:27 PM

And I guess my next ? for Tom the SQL expert is: Can the paragraph-add script be modded to only add extra line feeds to the end of Marriage fact notes? That is the only place I need extra lines now.  :P



#19 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3402 posts

Posted 05 April 2016 - 09:46 PM

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). This will affect all occurrences of that fact type. Or suppose instead you use an SQlite script to insert an appropriate number of carriage returns into all notes for a certain fact type (or types). Again, this will affect all occurrences of that fact type. Either way, even if the report looks good for most people there will almost certainly be a few people for which the general rule you are using for white space is not appropriate.

 

There are two basic solutions for this problem. The first solution is to edit the RTF file after it is produced. You can edit the RTF file as text with a text editor for some kinds of editing. For most kinds of editing, you would want to do the editing with Microsoft Word or some other word processor. The second solution is to make the required edits in your RM file. If you are controlling white space with sentence templates, you can override the sentence template for any particular fact on a case by case basis,no matter what you might have specified as the default in the fact list. If you are controlling white space with carriage returns in notes, you can edit any particular notes to make their white space different that the default you are using for all notes.

 

The first solution involves more work on your part on the back end - after you produce a report. The second solution involves more work on your part on the front end, getting things set up in RM itself so that reports are as nearly camera ready as possible as soon as they are produced. I have chosen the second option. But in truth, there are quirks in RM that nevertheless cause me to have to do a little back end editing. I have automated the back end editing as much as possible. But there is no way around the fact that it's hard work to produce really nice reports. This was true before I started using the point form format. And it remains true now that I am using the point form format. It's just that now that I'm using the point form format, I am vastly happier with my reports.

 

Jerry



#20 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6145 posts

Posted 05 April 2016 - 10:04 PM

And I guess my next ? for Tom the SQL expert is: Can the paragraph-add script be modded to only add extra line feeds to the end of Marriage fact notes? That is the only place I need extra lines now.  :P

You know me too well. I have fiddled the scripts to create a Version 2 that is changed in two or three ways:

  • I abandoned what Jerry says was my "more elegant" way of placing the [person] variable in favour of his inclusion of it with a carriage return in the Birth fact sentence. That is less clutter in the Edit Person screen but if it really is advantageous...
  • I have added a feature which identifies the last family event for each couple and appends two CR/LFs to its Note thus causing the spouse subsection to start a new paragraph, albeit with that one space indent.
  • These CR/LFs for the Note also include the private note "{CR}" with each so that they are visible in the Note Editor and the CR/LFs will survive transfer to another RM database

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 revised scripts are at the same place: Reports - Point Form Narratives Setup


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.