Family Historian User Group

Did a test report this morning and the new paragraph instructions in the sentence templates seem to have been ignored.

Does anyone know if there is anything I can change to make them work.

In FH7 leading white space in Sentence Templates are discarded.

That is a major retrograde step. What then is the point of having formatting options in sentence templates? I have just tested that and the new paragraph instruction is there.

It's not a major retrograde step. It's a minor bug that probably no one found during testing and I'm sure can be easily resolved in an update.

Nick,

You are probably right, but I interpreted the previous reply as it was a design decision. Hence my remark.

I like some aspects, particularly the spell checker ()but I can't seem to add place names etc to a custom dictionary) but I dislike the new Citation window, FH6 version was much more convenient use, the floating window is irritating.

I don't make design decision for CP, Dewi! -- I was just confirming what you'd observed, and that there's nothing you can do to make them work.

Understood, we're not all going to like all the changes. Some we'll get used to, some we'll have to put up with and others perhaps Calico Pie may change in a future update based on user feedback.

My guess is that they remove spaces because sometimes people add them by accident but they hadn't considered the possibility of someone deliberately adding a paragraph marker at the start. As a developer myself I know how easy it is to just not think about those kinds of 'edge cases' - they are rarely done deliberately and are easily fixed. Of course I could be wrong and it might be a deliberate decision to ignore your paragraph markers!

I'll add that a lot of software products automatically remove leading and trailing white space because it's usually an accident when it's created... Whatever I'm coding, I strip it out as a matter of course.

However, putting a <para> or <br> in doesn't usually happen by accident, so I'd guess removing them is a side effect of 'tidying up'.

It does avoid the situation when you end up with <para>{note}<para> for example, which looks dreadful if your note happens to be blank.

Removing unnecessary leading and trailing white space is normal practice as you say, but <para><br> etc are put there deliberately.

I have opened a ticket with support on this matter.

You will discover that it is not just <para> and <br> but any leading white space characters that get removed.
It is a signifcant 'change' from FH V6.

Won't <<para>{note}<para>> get around the blank Note case?

The spell-check and custom dictionary only works for single words.
So any place names involving multiple words are not handled, unless you enter each word separately.

I have yet to purchase version 7, but would add my comments to this thread as follows:

I have customised many of my sentence templates for use in narrative reports and a lot have <br> (or in some instances <para>) at the beginning to force a new line.

Nothing looks worse in a report than a mass of text in one large paragraph without such formatting.
Based upon dewilkinsons comments it seems that the <br> and <para> codes/commands should still be available for users to invoke but are unfortunately stripped out. Hopefully this situation can be remedied quickly by Calico Pie with a (‘bug’?) fix.
I’m somewhat surprised that this apparent oversight wasn’t picked up during beta testing (or if it was has not been actioned prior to release of V7) and that it took less than a day for an end user to discover the issue.

I wonder if the problem relating to books and indexes which I reported both here on this forum (9th July 2017)and to Calico Pie (12th July 2017) has been looked into? (See thread entitled 'Books & Index). I didn't receive any indication after raising a ticket as to whether this needed to be addressed by Calico Pie or was a deliberate action as to how the index algorithm worked in compiling the index.

Regards to all

Shiriki

Beta testers can't talk about what was found/not found during Beta testing.

Hi

I understand about about the confidentially agreement between Beta testers and the publisher, but with reference to my comment previously in parenthesis (or if it was has not been actioned prior to release of V7) it is still surprising it seems to have slipped the net by the publisher and as such not a reflection on any Beta tester(s).
Anyhow, hopefully it will be actioned by Calico Pie.

Best Regards

Shiriki

I have had a reply from Calicoe Pie and the issue has been passed to the developers.

Try to replace the space you need by the HTML code non-breaking space:
It is standard in programming to remove whitespaces from both sides of a string.

Andy

would an actual "non-breaking space" be better, or if you are using it in a list say a - or _ or >.

You are missing the point guys. It is not a space character that is being removed but <para> and <cr> line breaks used to start Narrative report sentences on a new line. Whereas now all the sentences run together in one large paragraph. That was why <para> and <cr> were introduced in the first place. But now they only work at the end or in the middle of a sentence.

tatewise wrote: ↑

09 Dec 2020 13:53

You are missing the point guys. It is not a space character that is being removed but <para> and <cr> line breaks used to start Narrative report sentences on a new line. Whereas now all the sentences run together in one large paragraph. That was why <para> and <cr> were introduced in the first place. But now they only work at the end or in the middle of a sentence.

I don't know how the text is generated in this context by FH. Could try replacing <cr> with \r\n. I would be surprised if this works since it is not working in this text.

I assumed the point of the suggestions were that by putting a different kind of 'space' character at the start (before the <para>) that didn't get removed it would mean that the <para> would remain too. But I have no idea whether those suggestions would work.

In a leading position like that no-break-space is not even retained in the Sentence Template the same as any other leading white space character. That is the same as in FH V6 and is the reason why <para> and <cr> were introduced.
Also HTML codes are not supported in Sentence Templates.

I realise it's not a great solution, but would putting a full stop before the <para> be a stop-gap until this issue is resolved?

I like the use of 'stop-gap' sic.
Yes, it works if you don't mind dot space dot at the end of the preceding sentence.

However, that reveals another problem in Narrative reports...
In the indented section for children that is usually in italics, any <para> or <br> line breaks upset the indent and reduces it by one tab stop. That does not happen in FH V6.

Hello all,

I would just like to say that I too do not understand why the <br> and <para> codes do not seem to work in V7. In my humble view the removal(?) of these two codes has made the narrative reports look very messy compared to v6.

I have not yet found a workaround, adding a period does give a line break, but of course you get a double period at the end of the previous line. .

Lets hope Calico Pie do a quick fix for us.

Thanks to all the experts in this User Group for their insights and advice, it's greatly appreciated!

David

In TMG a work round was to use undated and unnamed events.
My TMG import of one tree much edited in TMG to provide a complete text biography of my mother in law shows in fh many unlabelled and in many cases undated event fields.
These "facts" were used only to impose a carriage return within the text notes field.
I either started using TMG before one could format a carriage return or line break into notes or I didnt understand codes. The import to TMG was via Gedcom from Generations.

If you wish you can add your weight to the fix via http://www.calico-pie.com/osticket/open.php.

As has been said before, all leading white space characters (space, tab, newline) are removed from each sentence.
Whether it comes from <para> or <br> or characters in Note boxes does not matter. It all gets removed.

The only alternative workaround is to move the <para> or <br> codes to the end of Sentence Templates.