Family Tree Maker ASCII Issue
Brought to you by:
canajun2eh,
yalnifj
Menu
▾
▴
I'm exporting a GEDCOM from Family Tree Maker 2005 in ASCII and find it does not import perfectly with PGV 4.2.3. The import completes without error. I have found two problems when I view the data in PGV.
The first problem is that the characters ' and " do not convert properly. I'm able to fix this by opening the GEDCOM in WordPad and doing a search and replace.
The second problem is that on at least one record (I suspect there are more) the notes are not displaying. I can find them by editing the blank shared note, but when I try to save the change, PGV gives me an Error 20: Invalid GEDCOM format. I can find nothing wrong with this record. Everything displays fine except the notes. I'm thinking it may have something to do with the ASCII export from FTM. Just a guess
Any help appreciated.
Here is the record before importing into PGV:
0 @I0126@ INDI
1 NAME Elsie Ruth /Miller/
1 SEX F
1 BIRT
2 DATE 12 APR 1916
2 PLAC Elmsdale, N.S.
1 REFN 126
1 FAMS @F032@
1 FAMS @F041@
1 NOTE @NI0126@
0 @NI0126@ NOTE
1 CONC Elsie Cassidy is a native of Elmsdale, N.S. She has two children by her fi
1 CONC rst marriage: Daniel Albert Boyd (b. Oct 10, 1948 m. Dec 31, 1974 to Phyll
1 CONC is Croce d. 1996) and Elizabeth (Betty) Ann Boyd (b. Mar 23, 1951 m. J
1 CONC ul 6, 1974 to Steven Slifer). Dan lives in Glenville, North Carolina (200
1 CONC 2) and Betty in Filer, Idaho (2002). Elsie resides at 505 Dundonald St., A
1 CONC pt. 4K, Fredericton, N.B. E3B 9K6 (2002).
Peter, during the import, did you allow PGV to convert to UTF8 from ASCII? Its one of the options, and should definitely have been ticked. You might want to try re-importing, and check that setting, as otherwise there is nothing in that GEDCOM snippet that should cause PGV any problems.
As a general rule if PGV discovers things in the incoming GEDCOM that should be corrected, you should let it do so.
Just looking at your NOTE records - it looks to me as if there is something 'odd' about the naming. Is the reference really NI0126 and not N10126, (Note different character after "N") or is that something you've mis-typed here? If its deliberate, I suspect that might be the problem. Prefixes are 'usually' single character. Not sure, but I suspect PGV requires that - unless I'm introducing a red-herring!
Nigel
Nigel, the numbering is correct. FTM uses 2 characters for notes first the N and second the type of record the note is for (here indi). You could also have NF.
If I add a gedcom header/trailer to this, and import it into PGV, I get one INDI with one shared note. Everything looks OK. Were there any import errors?
I did let PGV do the conversion from ASCII and ther were no import errors. It seems FTM uses different codes for some characters. Easy to fix with search and replace in the original GEDCOM file using NotePad.
I think I've solved the second problem. It seems when FTM exports the GEDCOM, the first paragraph of notes begin with "1 CONC". PGV requires the first paragraph to begin with "1 CONT". When I manually edited the GEDCOM file the notes appear properly. The problem with this fix is that it's a lot of work. I had to to this manually to 1335 records. Took several hours. I big GEDCOM would be impossible. Either PGV needs to be changed to handle the FTM export or we need to come up with a was to automate a search and replace.
My concern now is that there may be other import errors due to the way FTM codes and PGV imports. Only solution I can think of it to test the import thoroughly. To do this properly we need a systematic process based on a knowledge of FTM and GEDCOM.
I imported your gedcom sample into PGV without any alteration. PGV *does* cope with NOTE records that begin with 1 CONC. (I remember writing the code that handles this!).
I suspect there might be some other factors here. Would it be possible to send me the gedcom, so that I can see the problem first-hand? fisharebest@gmail.com
I've sent the full FEDCOM file as requested.
I also still have a problem even after changing the first line of notes to "1 CONT". The note cannot be edited in PGV. When I try to save the changes, I get the same Error 20: Invalid GEDCOM Format. Something funny because records for which the notes imported fine can be edited in PGV.
Appreciate any help.
Peter Cassidy
Greg,
I too have played around with importing the above example from Steve.
I agree with you, PGV does indeed handle the Shared Notes with 1 CONC (It just simply strips them)
The only thing that I can see that would be needed is to take account of the extra letter in the Note ID to provide the anchor link to the shared note entry from where it is called in the indi.
This would mean changing line 1161 of functions_print.php from:
if (preg_match("/@N()+@/", $nrec, $match_nid)) {
to something like …
if (preg_match("/@N()+@/", $nrec, $match_nid) || preg_match("/@N()+@/", $nrec, $match_nid)) {
Brian
Further to my ast post, I notice that I can in fact save the chages to the record's notes provided I add at a paragraph to the note. Even an empty paragraph works. Now the question is why and how to fix the original GEDCOM to get a goo import.
Peter Cassidy
Earlier versions of PGV used to combine CONC lines whenever it needed to display / process records that included them. To improve performance, I changed it to merge them on import, and add them again on export. The importer will combine them onto the preceding 0 @XXX@ NOTE line, which is where the spec says they should start.
Peter has sent me his gedcom, and I can't see anything wrong. I've asked him for his config settings. It is possible (unlikely) that something here is causing this, but I need to eliminate it.
Brian - the hard-coded prefix is very nasty. This needs to change. Does it need the N at all?
More info: Whatever the problem is seems to be affecting the notes for every record. I just edited in PGV the last paragraph of a record I thoought was OK. PGV took the edit, but it duplicated the last paragraph before the edit. The edited pratgraph is retained. I can delete the duplicated paragraph, but have to leave a new paragraph at the end of the note. A blank paragraph works.
Peter
I think I have found the problem. Change SVN6565. If I revert the change, the gedcom loads OK. Lucasz, this was one of yours. Can you remember what this change was for?
Peter, can I ask you to edit one of your files: includes/functions/functions_import.php Line 557 looks like this:
Change it to
Then re-import your gedcom. When we merge CONC lines onto the previous line, we can either join them exactly (gedcom standards) or insert a space (some applications generate non-standard files).
However, there is an exception. If we are merging line #1 onto line #0 (programmers start counting things with #0), we must always add a space. This is so that
becomes
instead of
This SVN change removed the "line 1 is a special case" code. I don't know why.
Greg - I made the change and re-imported my gedcom. Notes are all now visible for the records.
I can edit the notes, but still have to add a blank paragraph at the end to save on the initial record that was giving the problem (126). Otherwise I get the Error 20: Invalid GEDCOM Format. I was able to edit another record (124) without the above problem. If necessary, I can live with this.
This is a bug, which is still present in the latest code, and is easy to fix. Raise a bug report to the effect that saving a note containing just one line of text (and no newlines) causes invalid gedcom to be generated.
Thanks for the help. The more I work with PGV the more impressed I am with what you all have done.
Appreciate your help,
Peter
Greg,
Ref
<<Brian - the hard-coded prefix is very nasty. This needs to change. Does it need the N at all?>>
Agreed, it is nasty, that is why I floated by you first as a "something like"
I do not remember even why the N was hard coded.
Feel free to improve, as I am not a wizard on REGEX as you know.
Brian