* Blank lines in report citations

[Mark1834]

When running a standard Family Group Sheet report, I was frequently seeing blank lines between source citations. Trial and error confirmed that these arose from lumped source citations that contained more than one line of text and a carriage return at the end of the last line. Much of my data was originally entered in FTM, and this required the carriage return to ensure correct report formatting.

FH seems to correctly handle multi-line text from individual sources, where it is indifferent to whether a single trailing carriage return is present or not, but treats multiple carriage returns as deliberately adding white space to the end of the text. It's not clear to me why it treats lumped sources differently. This sort of mirrors what you see in the user interface for entering data, where it displays a variable size Text From Source box for single sources, but only a single line for lumped sources with all the lines concatenated together unless you double click to open an additional "zoom" window.

This behavior suggests that Calico Pi are trying to restrict lumped source citations to a single line. Most of the time that is not a problem (GRO index entries for example), but I have kept secondary sources such as FamilySearch and FreeReg as lumped (as they were in FTM originally) and cited just for the principal event they describe. When I locate the original register entry, I split it out into a new single source and delete the lumped occurrence.

There seems to be a fairly simple workaround, by removing all the trailing carriage returns (easiest by stripping the relevant blank 5 CONT lines from the GEDCOM file, quicker than writing a plug-in for my relatively modest database), but that doesn't feel very elegant. Being pedantic, the carriage returns should be there, as they are line terminators, not the first character of new lines, and introducing an error in my data just to correct another error in FH presentation is asking for trouble in the future.

Any other suggestions or insight, please? Perhaps modifying the report template to handle both types of citation in the same way, but is that a sledgehammer to crack a nut (or even possible)?

[Gowermick]

Mark,
I too suffered from this effect (see my post Find and Replace for in Source Notes [Solved] (16145))
I had multiple ‘Have Image’ in my note field after lumping, and like you only spotted it in a report.
As you can see in my post, I couldn’t use find and replace to remove them, and your explanation about hidden carriage returns explains it.
My solution was to view the sources in the records window, where I could see which sources this affected (Reverse sort on note field to lift those with notes to top of list), then manually edit the note of each affected source record

Sadly, when viewing the notes in the records window, one cannot see the carriage returns,
In the property box I saw
Have Image
Have Image
Have Image etc

But in the records window I saw Have Image Have Image Have Image!

If only one could find and replace these hidden characters!

Perhaps Mike Tate will have the answer

[Mark1834]

You can see the carriage returns indirectly. Select the relevant text entry box, and move the cursor to the end using the arrow keys, without pressing Enter/Return. If the cursor sits at the end of the last line of text, there is no trailing carriage return. If it sits at the start of a blank line after the text, there is one. OK for monitoring new data entry, but very tedious for cleaning up existing data...

[tatewise]

Mark, you are correct that FH handles trailing newlines differently in Citation fields compared to Source fields.
There are no Report Options to customise that feature.
So I suggest you report that issue to Calico Pie using how_to:about#problem_reporting|> Problem Reporting.

The Edit > Find and Replace command cannot handle newline characters.

The Search and Replace Plugin does handle newline characters.
In many cases simply enter the newline in the Search or Replace box as required.

But to remove newline only at the end of a field and not earlier in the text needs LUA Pattern Mode (top right).
After entering the newline in the Search box follow it with $ which anchors it to the end of a field.
Leave the Replace box empty.
On the Extra Filters tab ensure only the required fields are selected.
e.g. For Citation Text From Source tick the Text From Source fields and select Citation (~DATA.TEXT)
Then Search & Replace will remove any trailing newline.

[Mark1834]

Mike,

Thanks for this. If there is an existing plug-in that does exactly what I want, then that's the obvious way to go. However, I can't get it to work correctly. Purely for testing, these screenshots are from looking for any newline character anywhere in any long text field, and it is not finding any at all. Clearly I am doing something wrong, but can you tell from these what it is please? I assume it is my Lua pattern that is wrong, as it works if I change that to something else.

1.PNG (22.71 KiB) Viewed 5962 times

2.PNG (34.85 KiB) Viewed 5962 times

[DavidNewton]

You don't need \n simply press the <ENTER> key, and if you want to look for final newlines then put in the $

David

[tatewise]

David is correct.
\n (and \t, \r, etc) are NOT LUA Pattern items.
They only apply within text strings within Plugin scripts, and thus not in this Search and Replace context.

[Mark1834]

Thanks gents, it works fine with this modification. I clearly don't understand Lua patterns fully, as they can contain literal characters as well as the various % specifiers, but that is a bit off topic so we'll save it for another day when I get back to writing my own code again (it's a dark evening winter activity for me) .

In testing I did notice a number of entries where a field consisted of just a newline character. I suspect these are mostly old notes and comments from many years ago that I did not fully remove - my oldest data have been through three transitions, from Pedigree to PAF, FTM, and now into FH, so it is not surprising the odd untidiness has crept in. Modifying the search text as shown below found these, so it has helped with a general tidy-up as well.

1.PNG (3.36 KiB) Viewed 5900 times

[tatewise]

Glad that helped.
Have you reported the original problem to Calico Pie?

[Mark1834]

Yes, and confirmed that the same effect is seen with Individual Summary Reports.