Jump to content


Formatting Glitch

  • Please log in to reply
3 replies to this topic

#1 JXInEastport



  • Members
  • PipPip
  • 11 posts

Posted 11 December 2013 - 10:32 PM

In a narrative report I sometimes want a Fact and its associated Note to start on a new line. I used to handle this by putting a carriage return at the end of the Note of the immediately preceding Fact. Unfortunately, this puts checkmarks in the Note column when there is nothing but the CR in the Note. Yes, I can live with this, but I almost found a better way.

For the Fact that I want to start on a new line, I can insert a CR before the formatting in the Customize Sentence dialog box. This would leave any formatting changes strictly associated with the Fact to which it applies.

However, this causes the first word, which is usually "He" or "She", to change to lower case "he" or "she." This does not seem to happen when the person's name is printed. This happens for various Fact types. Can this be fixed?


#2 Laura


    Advanced Member

  • Members
  • PipPipPip
  • 4276 posts

Posted 12 December 2013 - 12:22 AM

Add :caps to the first field starting the sentence, i.e. [Person:caps], [person:heshe:caps],

#3 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 2907 posts

Posted 12 December 2013 - 08:36 AM

I think this issue is a bit complicated, and the solution that's best for one RM user may not be the best for another RM user.

I use the "carriage return at the end of the previous note" solution. And yes you get a green check mark for a note that's really blank except for the carriage return. But that's among the least of your problems. Namely, the carriage return will be lost on a GEDCOM export or on a drag and drop operation. So if I have a problem with my database and somebody tells me to fix my database by dragging and dropping it into a new database, I lose all my carefully crafted formatting and the thousands of hours of work that went into it. Or if I make a GEDCOM to send to another user or to post at an online GEDCOM hosting site such as rootsweb.com, then I lose all my carefully crafted formatting and the thousands of hours of work that went into it. This is a nasty bug in RM4, RM5, and RM6 that wasn't there in RM1, RM2 or RM3, and which has never been fixed in RM4, RM5, or RM6.

The alternative is your suggestion of "carriage returns at the beginning of the fact sentence template". I experimented with this solution years ago. Initially, I was very pleased with this solution, but it has problems of its own. First of all, it works great for printed narrative reports, subject to the :caps thing that Laura reported. But this approach does not work for HTML files created by RM, nor for any GEDCOM you send anywhere else except to another RM user. For example, it doesn't work to send GEDCOM to your cousin who is a FamilyTreeMaker user, nor does it work to post to an online GEDCOM hosting site such as rootsweb.com.

Given these problems (and especially that it wouldn't even work with HTML files created by RM itself), I went back to the first option of the carriage return in the previous note. I came up with an ugly workaround for the RM bug that loses the carriage return by putting dummy, private information after the last carriage return. Which is to say, I terminate notes with a carriage return followed by {QQQQQ}. The use of the left brace { and the right brace } creates private information that I can choose not to print. I suspect that {} would have been sufficient without the QQQQQ, but I wanted a string that I could always find very easily. This is an ugly, ugly,ugly workaround, but what can you do? If I make a GEDCOM to send to somebody or to post online, it's easy to use a text editor and replace all the {QQQQQ} strings with nothing, which still preserves the carriage returns.

Finally, even with my chosen solution, there remains one little formatting glitch with narrative reports. Namely, each paragraph that's preceded by a note that ends with a carriage return starts with one blank character at the beginning of the line. I have found it impossible to do a global replace using Microsoft Word to remove this little bit of ugliness. So what I do instead is to edit the RTF file for the report with a standard text editor and I can remove the blank at the beginning of the line from there.

Notwithstanding these nasty little glitches with using the carriage returns at the end of the notes, my chosen method does make HTML files created by RM look correct, and it makes my paragraphs look correct when it's posted to GEDCOM hosting sites such as rootsweb.com

Unless you are worried about what your GEDCOM looks like when you post it online to GEDCOM hosting sites or send it to other users, or unless you are worried about what your reports look like when you make HTML files with RM, then your best bet is probably to add the carriage returns to the beginning of fact sentence templates, which is what you are already doing. But let me put one more caution out there for you. With my approach, ugly as it is, I can easily find all the places where I have inserted carriage returns at the end of fact notes to create a paragraph for the next fact note. In the case of sentence templates, there is no automatic way whatsoever to find any of the places where you you have added the carriage returns to the sentence templates. This may not matter to you, but I find it very bothersome.

RM simply doesn't make it very easy to control paragraphing or other such formatting and white space issues. All the stuff we do with RM about entering data and sources and with all the really cool RM features are completely irrelevant unless RM can make really good reports. If all you are doing is inputting data and never have any outputs, then there is no value whatsoever to what you are doing. Of course, there are lots of important outputs other than narrative reports, including GEDCOM and Websites and Family Group Sheets, etc. But narrative reports are the biggie for me.

Good luck with your reports.


#4 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 7659 posts

Posted 12 December 2013 - 09:49 AM

These issues are noted in our tracking system.