Reports – New Paragraph for General Note #paragraphing #reports

RootsMagic introduced in 2014 some very nice options for control of paragraphing of narrative reports after we had developed a number of scripts in 2011ff described in Paragraphing. There remain some issues for some people as of RM One was recently expressed by Wiki member aefgen:

Now another problem that I see has been discussed before: the last fact to print for a person in the narrative report is followed immediately by the general note for that person, even when you choose to have a space between each fact. That last fact (which will vary depending on what other facts are included in the database for that person) runs on into the text for the note.

Snippet from a narrative report showing the General (or Personal) note running on in the same paragraph as the last individual event.

Here is a script that works around this limitation by pre-pending to the General Note two pairs of CR/LF control codes to force a new paragraph. It applies the codes only to non-empty notes.

Same report as above after running the script.
The modified General Note as viewed in the RootsMagic Note Editor.

When executed on a database, the script creates two temporary views that persist as long as the SQLite manager keeps the database open:

  • vBareNote: the non-empty General Note stripped of one or two pairs of leading CR/LF in readable text,
  • vNewNote: the Note from vBareNote pre-pended with two CR/LFs in readable text, which has been applied to the database Note field in PersonTable.
vBareNote should always show the first line of text from the General Note with no leading blank lines, else there is an issue.

vNewNote should always show two empty lines before the text, else there is an issue.

The Note field in PersonTable is typed by RootsMagic to be BLOB (Binary Large OBject) so the script CASTs the readable text accordingly. That said, RootsMagic does not appear to preserve the type for this field converting it to Text when you next Save from the Note Editor. This change in type may be a useful indicator of edits done in RM after the last time this script was run.

After running the script, all the non-empty Note fields in PersonTable should be of type “BLOB” with two pairs of leading hex characters “0D 0A”, the ASCII control codes for CR/LF.

If a vBareNote cell does not display the first words of the Note, there is a problem with the original Note in PersonTable that requires manual attention either through RootsMagic (the vBareNote.PersonID is the RootsMagic RIN or Record Number) or through the SQLite manager. Re-executing the script after such manual edits will assure that the PersonTable.Note fields consistently have two leading CR/LFs.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.