This is virtually unchanged from FTW version 7.0

FTWGEDfx program and documentation

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)

[Off Site]GedChk, a program provided by the LDS to verify conformance with the GEDCOM standard, confirms some of these observations.

Dates

One area that GED2HTML bleats about a lot is date fields. Amongst others, GEDCOM 5.5 allows

FTW manages to get all these wrong as

FTWGEDfx

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.

CONC

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.