Narrative report - Descendants by Generation
|
Beverly Smallwood
I'm using version 7.0.15 of fh and attempting my first descendant narrative report. I have a event with sentence structured: {individual} <{value}> {note} {date} {place} {age}  As you can see, the sentence shows correctly, but when generating the report it put a period after the note, no space, then capitalized the date.  Is it behaving as designed or is this a bug? Can the note field be used within the sentence? Thank you, Bev |
|
|
|
Hi Bev, That is a known fault that has been discussed in the FHUG Forum several times: https://www.fhug.org.uk/forum/viewtopic.php?f=32&t=19695 https://www.fhug.org.uk/forum/viewtopic.php?f=40&t=20016 https://www.fhug.org.uk/forum/viewtopic.php?f=32&t=20389
It was reported to CP over a year ago but not fixed.
A partial workaround is to replace {note} with {%FACT.NOTE2%} but that does not work so well with the Report Note settings and may result in duplicate Note text in the Report.
|
|
|
|
Well spotted Beverly, I was so accustomed to the Note being the final part of the print and not optional in my previous software so the period would not have been an issue. My problem there was an unconditional period being forced before the Note.
Really if a period or comma is not part of the note then it should not appear is a simple observation unless there is a sentence variable parameter.
I would report the matter to CP, better several reports than one. On Tue, 27 Sep 2022, 07:15 Beverly Smallwood, <bevsmallwood@...> wrote:
|
|
|
|
Adrian Bruce
On Tue, 27 Sept 2022 at 11:01, Vyger <vyger88@...> wrote:
Mmm Maybe. One has to balance the needs of those who want to control the exact format of the resulting narrative, with those who really don't mind so long as the resulting narrative looks fine. The latter group are liable to omit the full stop / period at the end of a note (this isn't just me saying this, there was an internet story in the UK about people omitting full stops at the end of texts, etc) and logically the omitters ought to have their grammatic deficiencies fixed in the output - otherwise any decent word processor looking at the output will start complaining. I think in Bev's case, the {note} being in the middle, may not have been an option that was considered in the logic. (I confess I never put {note} into a sentence but add it in - after the narrative sentence - via the report level parameter - when it's wanted.) (Incidentally, I was one of those that tried to control my exact output formats by sentences using constructs such as < {date}>< {place}>. Unfortunately it didn't quite work for me and when I raised a query with CP they told me that the logic now attempted to control spacing etc, and my construct was sabotaging that logic - I only needed, they said, to enter {date} {place}.They may have advertised this advance but I'm quite likely to have skimmed that announcement without it sinking in "because I knew all about it already") Adrian |
|
|
|
Please don’t go into long discussions about punctuation rules. What Bev is experiencing is a BUG introduced by FH V7 that did not exist in FH V6. The {note} text should NOT be followed by a dot and then an immediately capitalised letter without an intervening space. i.e. “…note text.On 25 Nov…” is a BUG and should be “…note text on 25 Nov…”
|
|
|
|
colevalleygirl@colevalleygirl.co.uk
I wonder if you’re missing a point, Mike, because punctuation rules might be *the* point here. |
|
|
|
Phil Stokes
In the meantime, as a workaround or alternative solution for Bev, she could consider editing the individual fact sentence for the fact, to either add the desired note text directly into the existing fact sentence, or to replace the fact sentence completely with the text that she desires.
|
|
|
|
NO, you are all missing the point. Go look at the screenshots in the OP and in the FHUG Forum postings. In the Facts tab Sentence box it is correct, just as it was in FH V6. No dot and no capital letter. It is the Narrative Report that has a BUG. With an added dot and capital letter and missing space.
|
|
|
|
colevalleygirl@colevalleygirl.co.uk
Mike, we are not denying what is in the screenshots. We are questioning whether it is a bug (except the missing space, as I said above) or by design. (In which case it needs to be applied when rendering the sentence in the Fact tab -- a bug, but not the one you're claiming).
|
|
|
|
OK, so we are all agreed that there is a BUG in FH V7 that has been outstanding for over a year. The BUG definitely affects the Narrative Reports and may also be in the Sentence Box, but IMO the Sentence Box is correct for the following reasons. CP suggested using {value} instead of {note} as a workaround for attribute facts. So CP seem to have acknowledged it is a BUG in Narrative Reports, otherwise, they would have said it was by design. If it was by design then the same rules would have applied to {value}, but {value} behaves as it and {note} have always behaved until FH V7.
|
|
|
|
colevalleygirl@colevalleygirl.co.uk
IMO the Sentence Box is correct for the following reasons Whereas I'd argue that {value} will almost never be a full sentence, so I'd expect it to work as a fragment of text in places {note} (if it's expected to be one of more sentences) might not. |
|
|
|
Why should {note} be expected to be sentences any more than {value} which can hold hundreds of characters so is perfectly long enough for sentences? What if {note} is a fragment and not sentences? Nowhere does anything say it must be sentences. Events cannot use {value} so that is not a general workaround and {note} is the only viable option. Why did CP not simply say the {note} behaviour is by design? Why can’t you accept it is a BUG in Narrative Reports? There have been plenty of others introduced by FH V7.
|
|
|
|
I would agree with the opinion below and I also never considered the Note in the middle of output. In my previous software the note was not optional and was a follow on to the sentence. Sometimes the note as a 'comma' follow on and sometimes it was a 'period' new sentence. I lobbied for the punctuation to be conditional to the case of the first character of the Note which would have covered most instances in a smart manner outside of user over rides.
|
|
|
|
colevalleygirl@colevalleygirl.co.uk
Mike, nowhere does it say that Notes can be fragments either. In normal usage, if you write somebody a note, you don't write the middle bit of a sentence... which is why I said there might be an assumption that a note would be one or more sentences.
But the discussion is moot. We're agreed there's a bug, even if we don't agree where it lies -- it's an inconsistency that needs to be fixed one way or the other. We know it's been logged for a year. We know the value workaround only works for attributes. Phil Stokes has suggested another couple of options for workarounds. A reordering of the sentence to put {note} at the end would also work... On 31st August 1918 in Camp Jackson, South Caroline, USA, he was a private on the muster role for etc. |
|
|
|
Beverly Smallwood
Is there a size limit for the {value}? If not, I can include the fragment with the value in this case. On Mon, Sep 26, 2022 at 8:13 PM Beverly Smallwood <bevsmallwood@...> wrote:
|
|
|
|
colevalleygirl@colevalleygirl.co.uk
Mike told us above:
toggle quoted message
Show quoted text
{value} ... can hold hundreds of characters so is perfectly long enough for sentences? |
|
|
|
Beverly Smallwood
Jackson said:
I would agree with the opinion below and I also never considered the Note in the middle of output. In
my previous software the note was not optional and was a follow on to
the sentence. Sometimes the note as a 'comma' follow on and sometimes it
was a 'period' new sentence. I lobbied for the punctuation to be
conditional to the case of the first character of the Note which would
have covered most instances in a smart manner outside of user over
rides. I opened a support ticket with cp. I would hope that each other person encountering this would do so before working around the problem. Thank you for your help. Now I need to find all the places I used this 'feature' to make the sentence structure less stilted. Bev |
|
|
|
Something harks back to hearing a limitation of 100 or 128 characters. I'm not expert in Gedcom but I would imagine there is a design limitation which may vary program to program. I do remember Rootsmagic 7 truncated anything over one of the above numbers. Mike told us above: |
|
|
|
Bev, in FH you can achieve something similar to the TMG subdivisions by using labelled note text. That is then extracted using the function {=GetLabelledText( %FACT.NOTE2%, "Label: " )} The technique is described in the FHUG Knowledge Base article ‘Narrative Report Fact Sentence Templates’: https://fhug.org.uk/kb/kb-article/narrative-report-fact-sentence-templates/ See subsection ‘Custom Fact Fields’ for an example. It advises on the use of privacy [[ brackets ]] to exclude it from Reports.
You might find that is a better option than using the {value} method. Even using just {%FACT.NOTE2%} instead of {note} will work without having to find all the Facts involved.
|
|
|
|
There is a formal GEDCOM limit to the value that varies for different attribute facts from 3 to 248 characters. However, modern genealogy products often don’t even apply the GEDCOM line limit of 255 characters let alone any field length limits.
But such limits may be a good reason for persevering with the Note field that is unlimited in length and allows formatted rich text in FH V7.
|
|
|
