Narrative report - Descendants by Generation
|
Adrian Bruce
Sorry - no reason to put that control there for a new paragraph if you don't want to. I just tend to automatically think that way, that's the only reason it was there. My Notes for each event etc tend to be quite lengthy so it's a sensible way to split the presentation up. Adrian On Tue, 27 Sep 2022, 19:28 Beverly Smallwood, <bevsmallwood@...> wrote:
|
|
|
|
Beverly Smallwood
Thank you Adrian. I will probably do this in some form, but I don't understand why I must force it to a new paragraph? |
|
|
|
Adrian Bruce
Bev, if you want to make the published sentence less stilted, the ultimate is to wipe out the value, place, address, date from the output report, and just output the Note. It's what I do on a case by case basis where I need to (for instance) put caveats around the dates that can't be done any other way. Or write a start date, a middle (normally taken from the note), and then the end. What you need to do is alter the sentence specific to that fact to read <para>{note}
Anything else seems to result in issues like the footnote references migrating to the previous fact. The <para> bit simply creates a new line. Then your entire Note for that fact gets printed. Leave the value, date, place, address, etc (if there is any etc) in place - they won't get printed, but they can be interrogated in queries. Adrian On Tue, 27 Sep 2022, 17:34 Beverly Smallwood, <bevsmallwood@...> wrote:
|
|
|
|
colevalleygirl@colevalleygirl.co.uk
On Tue, Sep 27, 2022 at 06:11 PM, Mike Tate wrote:
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. Of course, changing the behaviour now would require people who have relied on the new behaviour to change their data as well. I suspect it's a no-win situation for anyone. |
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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: |
|
|
|
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 |
|
|
|
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
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, 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. |
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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. |
|
|
|
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
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).
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
colevalleygirl@colevalleygirl.co.uk
I wonder if you’re missing a point, Mike, because punctuation rules might be *the* point here. |
|
|
|
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…”
|
|
|
