This is virtually unchanged from FTW version 7.0
Generated with the default output parameters GEDCOM=5.5 and Destination=FTW.
0 HEAD 1 SOUR FTW 2 VERS 7.00 2 NAME Family Tree Maker for Windows 2 CORP Genealogy.com 3 ADDR 39500 Stevenson Pl. #204 4 CONT Fremont, CA 95439 3 PHON (510) 794-6850 (this is the correct structure, unlike the other uses of "PHON") 1 DEST FTW 1 DATE 1 CHAR (e.g. ANSEL or ANSI) 1 SUBM @SUBM@ 1 FILE 1 GEDC (empty) 2 VERS 5.5 2 FORM LINEAGE-LINKED (new for V8.0) 1 _SCHEMA (empty, non standard GEDCOM structure) 2 INDI (empty) 3 _FA1 to _FA13 (empty) 4 LABL 3 _MREL and _FREL (empty) 4 LABL 2 FAM (empty) 3 _FA1 to _FA2 (empty) 4 LABL 3 _MSTAT and _MEND (empty) 4 LABL 0 @SUBM@ SUBM 1 NAME (not in First /Surname/ format) 1 ADDR 2 CONT 2 PHON (invalid GEDCOM 5.5, should be "1 PHON") 0 @I<XREF>@ INDI 1 NAME (can occur more than once for alternative names) 2 SOUR @S<XREF>@ 1 SEX 1 ALIA (wrong usage of GEDCOM 5.5 tag. Treats single names as surnames GED2HTML generates a lot of errors for this. FTW has lost sight of the purpose of this field, I use it for Nicknames) 1 TITL (used by FTW to be the Name Prefix) 1 OCCU, RESI, SSN (empty, these are attributes and the data should be on this line according to the GEDCOM 5.5 standard) 2 DATE 2 PLAC (incorrectly used to contain the data) 2 SOUR @S<XREF>@ 1 BIRT, BURI, WILL, PROB, EMIG, CENS, BAPM, IMMI (empty) 2 DATE 2 PLAC 2 SOUR @S<XREF>@ 1 DEAT (empty) 2 DATE 2 PLAC 2 SOUR @S<XREF>@ 2 CAUS 3 SOUR @S<XREF>@ (GEDCOM 5.5 does not provide for "SOUR" at this level) 1 EVEN (empty) 2 TYPE (e.g. Honours) 2 DATE 2 PLAC (or details) 2 SOUR @S<XREF>@ 1 REFN 1 ADDR (GEDCOM 5.5 does not provide for "ADDR" at this level) 2 CONT 2 PHON (invalid GEDCOM 5.5, should be "1 PHON") 1 _MDCL (medical information, non standard GEDCOM tag) 2 SOUR @S<XREF>@ 1 FAMS @F<XREF>@ 1 FAMC @F<XREF>@ 1 NOTE @NI<XREF>@ (general individual notes) 0 @NI<XREF>@ NOTE (can also be NF or NS) 1 CONC 1 CONT 0 @F<XREF>@ FAM 1 HUSB @I<XREF>@ 1 WIFE @I<XREF>@ 1 CHIL @I<XREF>@ 2 _FREL & _MREL (e.g. Natural, Adopted, Foster) 1 MARR (empty) 2 DATE 2 PLAC 2 SOUR @S<XREF>@ 1 _FA1 (generated by Divorce fact) 2 DATE 2 PLAC 2 SOUR @S<XREF>@ 1 EVEN (empty) 2 TYPE (e.g. Banns) 2 DATE 2 PLAC 2 SOUR @S<XREF>@ 1 _MSTAT (e.g. Unknown, Single, Partners) 1 _MEND (e.g. Divorce, Separation) 1 REFN 1 NOTE @NF<XREF>@ (marriage notes) 0 @S<XREF>@ SOUR 1 TITL 1 AUTH 1 PUBL 1 NOTE @NS<XREF>@ (generated by Comments & Quality master source fields) 1 REPO (empty—this is incorrect, it should point to a Repository record GED2HTML generates a lot of errors for this) 2 NOTE @NS<XREF>@ (generated by Location master source field) 2 CALN (can be empty) 3 MEDI (e.g. Microfilm, Book, Church Record, Electronic) 0 TRLR (All SOUR @S<XREF>@ citation entries can have the form below) 2+ SOUR @S<XREF>@ 3+ PAGE 3+ DATA (empty) 4+ TEXT (citation text) 5+ CONC 3+ NOTE @NS<XREF>@ (occurs if you override the default citation)
GedChk, a program provided by the LDS to verify conformance with the GEDCOM standard, confirms some of these observations.
One area that GED2HTML bleats about a lot is date fields. Amongst others, GEDCOM 5.5 allows
- ABT <DATE> for about.
- BEF <DATE> for before.
- AFT <DATE> for after.
- BET <DATE> AND <DATE> for a range.
- FROM <DATE> TO <DATE> for a period.
- (<TEXT>) for any phrase with information.
FTW manages to get all these wrong as
- ABT. <DATE> (extra full stop).
- BEF. <DATE> (extra full stop).
- AFT. <DATE> (extra full stop).
- BET. <DATE> - <DATE> (extra full stop and a dash instead of AND). When the two dates are in the same year, FTW compresses this, omiting the year for the first, which is not permitted in GEDCOM 5.5. Also FTW doesn’t distinguish a range from a period.
- UNKNOWN and PRIVATE (not in parentheses). There may be other phrases which I have not discovered. In any case, GED2HTML 3.6 doesn’t support them, even in parentheses, so it hardly matters.
- Pre 1752 “Double dates” are output correctly as, for example, 1741/42. Unfortunately GED2HTML ignores the “/42” giving some people the wrong impression, even though it is actually correct for the calendar at the time.
To facilitate the successful conversion of FTW output by
GED2HTML I have written a trivial program to fix many of these
problems. This program called
FTWGEDfx can be
downloaded from this site.
There is another major situation where FTM manages to mis-interpret the GEDCOM standard, but I am inclined not to criticise this too harshly because almost every other program, including GED2HTML does so as well. This is regarding the interpretation of the CONC statment.
The standard says (Appendix A) that the value of CONC is to be connected to the value of the superior line without a space or newline character. Whereas the value of CONT is to be connected to the value of the superior line including the new line character and all but the first space after the CONT. For example:—
0 @NF1234@ NOTE This is how the GED 1 CONC COM standard would like continued comments to be writ 1 CONC ten with the lines running from one statament to the ne 1 CONC xt without any whitespace. 1 CONT But a forced (and indented) new line with the CONT state 1 CONC ment. A line to be continued with CONC can never end with a who 1 CONC le word. Leading whitespace on CONC is ignored.
Most programs and, indeed, even an example in the standard itself (end of chapter 2), don’t interpret it like this. The more normal implementation is to treat the new line before a CONT as a hard new line, but the new line before a CONC as a soft new line including at least one whitespace character. Writers of HTML will be familiar with this style, thus:—
0 @NF1234@ NOTE This is how most software 1 CONC actually codes the statements assuming a soft newline 1 CONC before a CONC statament. 1 CONT But a hard (and indented) new line with the CONT statement. 1 CONC With this interpretation, a line to be continued with 1 CONC CONC must end in a whole word. Again, leading whitespace on 1 CONC CONC is ignored.
As this is how GET2HTML interprets it as well, I have not attempted to correct the output.