Family Historian User Group

Hi. I've written a program to load the GEDCOM from Family Historian, rearrange some of the content and write it back out.

In the process I've noticed some oddities that probably aren't important, but annoying because I can't find any definitive guidance in the GEDCOM standard.

A good example is using the NOTE tag followed by several CONTs:

1 NOTE For descendants see...
2 CONT
2 CONT Note continues after blank line.

FH5 stores this with a space following the first CONT.

Now I could argue that in this first CONT the data (value) is empty, so it's improper to include a space delimiter.

Is anyone better clued-up, please?

Along the same lines, I have quite a few instances of empty Note and Occupation fields. These show the same pattern of tag plus space before newline.


ID:6866

In my experience trailing spaces in text files can be ignored in most processing systems.

Personally I have given up trying to mod gedcom outside of FH as plugins allow you to do pretty well everything you could want to do with gedcom files.

OK, Jane, thanks for that. I did suspect most packages would be forgiving.

Point taken about plug-ins (and hearty congrats to Simon for providing this facility), but I'm woefully first-base here and couldn't contemplate code to combine Place Hierarchy with Source Page and Census Notes with Source Text (with a certain amount of 'intelligence').

Besides, this way I can do stuff that FH won't allow (e.g. add a descriptor to census events) to improve the transfer to Ancestry.

Anyway, I'm an old dog and happy with my VB/VBA debugging environment.

Happy days.

I'm saying this without checking the GEDCOM manual but I suspect that CONT is always followed by a trailing space and CONC is never followed by a trailing space. So clearly(?) the space following CONT will always be there as default. Now whether or not that is necessary is a bit of a moot point, but if I had to make a choice I'd go with the space to avoid confusion with CONC type processing. And hope, as Jane says, that it doesn't matter.

PS Paul - glad to see someone else is happy with VB/VBA...