I have complained a number of times that RM8’s descendant narrative reports do not go to a new line when transitioning between the first spouse’s facts and the couple’s facts. A workaround is to add a carriage return to the beginning of the sentence for the Marriage fact and probably for several other couple facts. To a certain extent, this problem is tied into my use of point form sentence templates.
But I have discovered that there is a similar problem using RM8’s default sentence templates. Namely, there is no blank at all between the first spouse’s facts and the couple’s facts. I have attached a screen capture that illustrates the problem.
I guess that’s kind of my point. An analog throwback still used by digerati, many (most?) of whom probably never saw an actual carriage physically return to start the next line, or a finger “dial” a rotary phone. Except maybe in the movies.
Actually, a carriage return (ascii 13) returns the print position to the beginning of the current line and a line feed (ascii 10) moves the print position directly down to the next line without positioning to the start of the line.
mac and other unix systems may interpret them differently, I’m sure Rooty will chime in.
If you place a “carriage return” in an RM sentence template or in a note, you do so with the Enter key on a PC and I assume with a similar key on a Mac. What actually gets stored in the RM database is a two byte sequence, 0D0A in hex, 13,10 in decimal, Ctrl-M, Ctrl-J if that’s the way you want to think about it, or Carriage Return + Line Feed if that’s the way you want to think about it.
That’s the Windows convention rather than the UNIX or Mac convention, but it’s hard to imagine that RM on a Mac would put characters into a sentence template or into a note differently than would RM on a PC. If it did, the same RM database could not work correctly on both a PC and a Mac without garbling your notes.
The hex 0D and 0A characters cannot appear in GEDCOM because they would be interpreted as the end of GEDCOM record. Rather, RM uses an appropriate combination of CONC and CONT tags to create the new line effect. Software importing GEDCOM is expected to reconstruct the carriage return + linefeed sequence from the CONC and CONT tags. Unfortunately, not all genealogy software creates and interprets the CONC and CONT tags in the same way, which sometimes can create bad spacing in notes that are transferred by GEDCOM.
The hex 0D and 0A codes are the old ASCII codes but they still work in UNICODE. RM’s database is UNICODE. In particular, RM’s database uses the UTF-8 encoding of UNICODE.
Brings back memories of the typing class I took in 8th grade.