GED2HTML: A GEDCOM to HTML Translator

Eugene W. Stark

Overview

• About the program.
• Version number of the currently available release.
• What's New in the current release.
• Downloading the program.
• Running the program.
• Output produced by the program.
• Uploading the output to your Web provider.
• Customizing the output via options settings.
• Modifying the GED2HTML output program.
• Commonly encountered problems in running GED2HTML.
• Miscellaneous other topics.

If you are reading an outdated version of this document that was distributed with an old version of GED2HTML, you will always be able to find your way to the current version of the program and documentation by starting here.

Copyright and License Information

Copyright © 1995-1998 Eugene W. Stark.

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the following acknowledgement:

   This product includes software developed by Eugene W. Stark.

4. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission.
5. No copying or redistribution in any form for commercial purposes is permitted without specific prior written permission.
6. This software may be used, for evaluation purposes only, for a period of no more than fourteen days. Use of the software for a period beyond fourteen days, or use of the software for anything other than evaluation purposes, requires written permission from the author. Such permission may be obtained by paying to the author a registration fee, as described in the documentation accompanying this software.

THIS SOFTWARE IS PROVIDED BY EUGENE W. STARK (THE AUTHOR) ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

GED2HTML home page

Registration

I can now offer you three ways to pay the registration fee. By far the fastest and easiest way for you as well as for me is for you to pay using the Kagi Software Web page at: http://order.kagi.com/?ES&S. Kagi Software is a payment processing service I have engaged for this purpose. They forward the payment to me after taking a commission of a few percent and also deducting the fees charged by the credit card company. To use the Kagi Web page, you must pay by credit card, and you must supply them an E-mail address they can use to sent you your registration acknowledgement after your payment has been processed. Generally, this will occur within 24 to 48 hours after you submit your payment.

A second way to pay, which anyone can use, is to remit payment to Kagi using the REGISTER.EXE program that is packaged together with the Windows distribution of GED2HTML. With this method, you may send payment in a variety of forms, including credit cards via FAX, and personal checks via postal mail. Kagi will send you an acknowledgement either by E-mail (preferred) or via the postal service, and will forward the payment to me after deducting their commission. To pay this way, simply run the REGISTER.EXE program, fill in the form, and send the payment as instructed. When you pay using this method, you should allow sufficient time (perhaps a week, depending on where you are mailing it from) for your payment to reach Kagi, a few days for Kagi to process your payment (depends on the form of payment -- see Kagi's Web page for details), and sufficient time for the acknowledgement to reach you again.

A third option is to send payment directly to me. To do this, you must be able to procure a money order or check drawn on a US bank (personal check is OK) for $20 US currency. Please make funds payable to "Eugene W. Stark" and mail payment to me at the following address:

Eugene W. Stark
14 Landing Lane
Port Jefferson, NY 11777
USA

When I receive your registration fee, I will send you an acknowledgement of your registration, and place you on a mailing list to receive announcements of future updates to the program. You will also receive a password that will enable you to download the full version of the program from here. The full version of the program does not produce the UNREGISTERED message in the output files that the "demo" version of the program produces. Your registration fee entitles you to use any updated version of the program I release within two years of receiving your fee. Your registration fee helps me to justify spending time improving this program and responding to E-mail from users. Thanks!

GED2HTML home page

GED2HTML: About the Program

I wrote the original version of this program because I wanted an easy way to convert my own GEDCOM data to HTML for presentation on the World Wide Web. Version 1 of GED2HTML, written for Unix in early 1994, was built around a YACC parser. This version was based on the GEDCOM 5.3 draft standard. A Windows 3.1 version was created in late 1994, and a user-configurable output template language was also added at that time. As I gained experience with how GEDCOM is actually used in practice, I realized that the YACC-based parser was too inflexible to handle the full variety of GEDCOMs that actually exist. So for GED2HTML version 2, released in mid-1995, I wrote a new parser that would accept essentially "any" GEDCOM file, and would only complain about grossly malformed input. Since Version 2.0 many people have used this program to place their family history databases on the World Wide Web. Version 2.5b, released in April, 1996, was a particularly long-lived and successful version.

Version 3.0 of GED2HTML incorporated yet another major revision of the program. I undertook this revision because I wanted to accomodate better the newly adopted GEDCOM 5.5 standard, but could not do so in a reasonable way without redesigning the core of the program. In addition, the template language used in version 2 was incredibly cumbersome and difficult to use, and I felt the complexity of the output templates was limiting my ability to handle the additional information that could be incorporated into a GEDCOM under the 5.5 standard. Version 3.0 featured a newly designed output language that can actually be programmed by mere mortals, including me.

Well, at least me. One of the disadvantages of the new output language is that you pretty much have to be a programmer to make any kind of substantial changes to the output format. Regrettably, the situation has not improved much in subsequent versions. In the current version (3.5), the standard output program is itself over 2500 lines of code! However, the output language introduced in version 3.0 has given me the flexibility to accomodate many of the suggestions that I have received from users of the program over the past few years. It seems that my "to do" list is never empty, but I feel that I have continued to make many substantial improvements in the program since version 2.5b.

Over the course of its lifetime, GED2HTML has been used in a variety of ways. However, at present most people are using this program as a ``black box'' for quickly transforming their GEDCOM data into a form suitable for presentation on the World Wide Web. A good starting point for finding many of these databases is the GENDEX index server, which at the time of this writing provides links to data pages on nearly 7 million individuals in over 2000 databases, a large percentage of which were processed into HTML using GED2HTML. The largest database that I know about that has been processed with GED2HTML (running under FreeBSD Unix) is a nearly 40MB file that contains data on over 160,000 individuals in over 1.8 million lines of GEDCOM. I have used versions of this program to prepare my own much more modest data (about 1000 individuals) for presentation on the World-Wide Web. You can view the results by starting from here. From my GEDCOM file, I produced approximately 700 individual files, which are linked together among themselves and to my hypertext family history document.

Though versions 2.3a and earlier of this program were released as freeware, around the time of the release of version 2.3a I realized that I was spending quite a bit of time responding to E-mail from users of the program. From the E-mail correspondence, it became clear that much better documentation was required. Besides that, the program itself had grown, revisions were starting to take more time, and had become a bit less fun and more work. I also began running the GENDEX WWW Genealogical Index site on the World Wide Web to try to establish a central index of as much as I could of the data on the Web that was prepared using GED2HTML program (and other compatible software). To justify the amount of time I was spending on this work, I decided that GED2HTML version 2.4 and all subsequent versions would be released as shareware.

Over the past few years I have corresponded with hundreds of people about this program, and quite a number of them have sent me useful suggestions which I have tried to incorporate into the current version. Though it would be impossible for me to name everyone from whom I have received a valuable suggestion, I would like to convey special thanks to Birger Wathne for contributing useful ideas and code for the first versions of this program, and to a number of other users (including, but not limited to, Annelise Anderson, Allyn Brosz, Susie and Kerry Jane Dunavant, Bob Fieg, W. Wesley Groleau, Brian Mavrogeorge, Steve Messinger, Mike Schwitzgebel, and Doug Smith) of various early versions of the program who took the trouble to send me their bug reports and problematic GEDCOMs. Special thanks to Jean-Philippe Ménard for the French translation, Wilm Boerhout for the Dutch translation, Peter Springer-Ferazin for the German translation, Olav Overdahl for the Norwegian translation, Ezio Ajmar for the Italian translation, Lars Blomberg for the Swedish translation, Jørgen Bak for the Danish translation, and Matti Rekunen for the Finnish translation. I am very grateful to Annelise Anderson for her beta testing efforts of version 3.0, which found a number of horrible bugs that I don't want to talk about. I'd also like to thank everyone else who sent me registration fees, along with their kind words that make all the work I did on this program worthwhile.

GED2HTML home page

GED2HTML: Current Version

GED2HTML: What's New in the Current Release

Another mostly bugfix release that supersedes version 3.5d. The following changes were made since version 3.5d:

• Incorrect codes in internal tables for the ANSEL character set were corrected. This problem caused certain international characters, including "es zet", slash o, thorn, ligature ae, and various other symbols, to appear incorrectly in the output for certain GEDCOMs.

• Some minor changes were made to the Swedish language tables.

• Failure of GED2HTML to correctly interpret dates with trailing spaces was corrected.

• A missing comma was added to the output program. This was causing a mysterious "00" to be output after the LDS "Temple" tag.

• Father, mother, and child links from family group sheets were changed to point to places that were a bit more reasonable. In particular, an attempt is made to always point such links to the most suitable family group page, if such exists, giving preference to a page that records the marriage of the target individual over one that records that individual as a child.

• Code was added to the output program to link to notes and sources for "Married:" events, the same was as was already done for "Born:" and "Died:" events.

• Finnish was added to the list of supported languages.

• Some little-used and/or old GEDCOM tag names that appeared to be coded incorrectly in internal tables were corrected.

Another bugfix release that supersedes version 3.5c. The following problems in version 3.5c were fixed:

• A problem was corrected that caused the alphabetical index tabs not to point correctly to the proper surnames in case there were null surnames in the GEDCOM input.

• A problem was fixed in which children's marriage date/place information was coming out blank in the parents' family group sheet.

• In family group sheets, father/mother links now point to the page for the correct marriage, rather than to the first marriage for the specified individual.

• Superfluous blanks that were being output in the gendex.txt file were removed.

• A bug in the output language that prevented subscripted variables from working properly was corrected.

Another bugfix release that supersedes version 3.5b. The following problems in version 3.5b were fixed:

• The "standard.g2h" output program was reworked to fix brokenness in the support of the INLINE_NOTES option, and to make the INLINE_NOTES and INLINE_SOURCES options behave like the documentation says they are supposed to.

• A problem was fixed in the "standard.g2h" output program that caused it to fail during generation of the alphabetical surnames index in cases where there were individuals with no surnames.

• The error message claiming that a date is "missing non-GEDCOM-5.5-compliant: was toned down to state only that the the date is "missing or uninterpretable". This is because there are a couple of constructions in GEDCOM-5.5 dates that GED2HTML does not yet understand, so it seems best not to declare arrogantly that they are not GEDCOM-5.5-compliant.

• The behavior of the GED2HTML.EXE dialog screen was changed so that selecting an options file through the use of the BROWSE button causes that options file to be loaded immediately. The failure of this loading to occur has confused many people in the past.

This additional bugfix release supersedes version 3.5a. The following problems in version 3.5a were fixed:

• A problem was fixed in which the day of the month portion of dates failed to appear in the HTML output.

• A problem was fixed that caused error messages and failure of the program to generate output when the SURNAME_WIDTH parameter was set to a nonzero value.

• A problem was corrected that caused children in family group sheet output to be listed with the same marriage place as their parents.

• The number of error messages printed out in case of non-GEDCOM-5.5-compliant date strings was limited, with full details going to the error file.

This bugfix release supersedes version 3.5. The following problems in version 3.5 were fixed:

• A problem was fixed in which notes that had CONC in them were being truncated after two lines.

• A workaround was implemented for the situation in which the GEDCOM file contains non-GEDCOM-5.5-compliant date formats. (Brother's Keeper appears to be a significant culprit here.) GED2HTML v3.5 would silently interpret such dates incorrectly. Version 3.5a now complains loudly about the incorrect date format, and then simply uses the date string verbatim, rather than trying to interpret it. This means that non-compliant dates will not be translated according to the selected output language or locale.

• A mistake was corrected regarding the transmission of the "Output Program File" parameter between the GED2HTML.EXE dialog screen and the G2H.EXE program. The dialog screen was using the old parameter name TEMPLATE_FILE, rather than the new parameter name OUTPUT_PROGRAM.

It's been a long time since version 3.1a, and as I've made a fairly substantial number of improvements, I've bumped the version number several notches. I didn't go all the way to 4.0, though, because the changes to the program are primarily evolutionary, rather than revolutionary. The following summarizes the most important changes. There have also been many other minor changes and fixes.

• The family group sheet output format has been integrated into the standard output template program, and it is selectable via the "Additional Options" field of the dialog box.

• A number of parts of the GEDCOM 5.5 specification that were not handled before, or were handled only minimally, are now handled more fully. This includes sources and source citations, as well as repository information.

• Dates in the GEDCOM are now interpreted by GED2HTML, if possible. This enables dates to be produced in the HTML output in a format appropriate for the desired output language (English, French, etc.)

• The separate output programs for each individual output language have been merged into a single standard program. This makes it possible to change the output language via program options, without having to also use a different output program. The disadvantage is that the standard output program is now a daunting piece of code of over 2500 lines, which probably makes it fairly difficult for non-programmers to make substantial modifications.

• The output template now provides some control, via options variables, of whether notes and sources appear on the same page as the individual or family to which they pertain, or else on a separate notes page.

• For surname indexes that aren't too long, the standard template now uses an alphabetical style that seems to be popular on the Web. To support this, the output template language was extended with comparison operators on both integer and string values.

• Some non-backward-compatible changes were made to the output language in order to support some of the new features in this release. These changes primarily have to do with the additional of additional types of values, and changes in the meanings of certain qualifiers. If you have made substantial customizations to the output program, you will want to review the output language definition.

It's sort of embarrassing to issue a new release a few days after a previous release, but in this case I had to do it because of a bug in the new "automatic living detection" feature that could potentially cause me to get a lot of E-mail.

• A bug was fixed that prevented many dates from being interpreted correctly, which would in turn cause individuals that should have been presumed "living" not to be flagged properly.

This release consists of minor bug fixes and changes I introduced in response to E-mail from users, plus a new experimental output format, ability to process LDS ordinance information, and a feature for automatic flagging of "living" individuals.

• A bug was fixed where when an individual had multiple NAME records, the last one was chosen as the primary name, rather than the first.

• The standard template was modified to add an indication of whether the family line continues with a child.

• A new experimental template "famgrp.g2h" was added, which produces the individual data pages in "family group" format, much in the style of another popular GEDCOM to HTML converter program. Although the fact that I could code this template illustrates the flexibility of the GED2HTML output processor, it wasn't as straightforward as I would have liked. In the future, I will be looking into generalizing the output language to make it easier to generate output formats radically different than the "original" GED2HTML format.

• Some problems with umlauts in ANSEL-encoded GEDCOMs were fixed.

• Processing was added for LDS ordinance information.

• A bug was fixed that caused a GPF or invalid page fault when processing a GEDCOM that had undefined cross-reference links to individuals.

• Several new options variables were added that make it easier to set background colors or images on the generated HTML pages.

• Added a feature by which GED2HTML will automatically presume a person to be living if they are born after a specified year and have no explicit death information.

• Support for output in German and Norwegian has been added.

• The program is now somewhat more forgiving in case there are undefined cross-reference ID's in the GEDCOM. Previously, it would often terminate prematurely in the output phase. Now, it should complete producing the output files in most situations.

• A bug was fixed that prevented options beginning with a digit from being recognized as strings, even when there was a preceding double quote.

• Some improvements and extensions to the standard template program.

This version incorporates a few bug fixes and extensions since version 3.0. Specifically, the following changes were made:

• The processing of "individual attributes", such as EDUC, RELI, RESI, was broken. These should now work much better.

• The GED2HTML dialog box would mysteriously fail to save options settings in certain situations. This was due to a parameter being set too low, which limited the number of changed options that could be recorded in an options file to 10. I have now increased this parameter to 100.

• I got rid of a long directory name (templates) that was causing certain unzip programs to choke on the distribution file. The template directory is now called "template".

Version 3.0 represents a major rewrite of a large portion of GED2HTML. The main objective of this rewrite was to modify the internal design of the program to obtain flexibility for accomodating the GEDCOM 5.5 standard as fully as possible. There were three main problems with the old design that stood in the way of doing this: (1) the output template language was too complicated, making it infeasible to add further features or information to the output pages; (2) the internal data structures could not accomodate the additional information allowed by GEDCOM 5.5 without using excessive amounts of memory; (3) the method of specifying program options was too complicated and ad hoc to support the introduction of additional options for output customization. The following is a brief summary of the main changes in functionality between 2.5b and 3.0:

• The output template language has been completely redesigned. The new language is much more like an ordinary programming language, and it actually has some features for finding errors in templates before they are run, as well as for debugging templates while they are running. The several output templates that existed in the previous version have been combined into a single template, and recoded in the new language.

• The method by which customization options are set has been completely revised and made more uniform. Nearly all options are now controlled by setting variables in the output template interpreter. Many more customization options were added.

• Under Windows, the GED2HTML.EXE dialog box has been redesigned and substantially extended, so that essentially any program option can be set from it. It is now possible to save options settings to a file and recall them on a later run, making it much easier to associate a different collection of options settings with each GEDCOM one might wish to run. The dialog box has been enhanced with "Browse" and "Save As" common dialog boxes for specifying the GEDCOM, options, and template files.

• The program now has a native Windows 95 version, as well as a Windows 3.1 version. The Windows 95 version is several times faster than the Windows 3.1 version.

• An attempt has been made to make GED2HTML compatible with the current GEDCOM 5.5 standard. Besides INDI and FAM, both both NOTE and SOUR at level zero are now fully supported. Though other level-zero records permitted by GEDCOM 5.5 are not yet supported, the internal design of the program has been reworked so that it should be much easier to add support for these records in future releases.

• Support for several character sets other than ISO-8859-1 has been added. In particular, the program should now do a reasonable job with international characters encoded in ANSEL, ISO-8859-1, and IBMPC character sets under DOS code pages 850, 863, and 437.

• The program now supports output in French and Dutch as well as in English.

• A two-level hierarchical surnames index is now supported, to reduce the size of the surnames index files for very large databases.

• Notes and sources files can be split up into pieces, so that each piece is a manageable size.

• The registered and "demo" versions are now identical, except for the following: (1) the demo version outputs an UNREGISTERED message on each HTML output page; (2) substitution of new output template programs is not supported in the demo version; (3) the demo version will read in, but not produce output for, GEDCOMs containing over 5000 individuals.

• It is now possible, using an option setting, to switch between the hash-based assignment of individuals to files and directories of version 2.5b, and the alphabetical assignment used in older versions. This should alleviate a common complaint about 2.5b.

• The behavior of the !LIVING feature has been placed under the control of the output template program. The default behavior is to output the name of a living individual, but no other information. More or less information can be included by changing the output template program.

• Better error messages are produced in response to problems with the GEDCOM being processed.

• It is now possible to access some of the information in the 0 HEAD GEDCOM header record.

• Fixed bug (again!) which caused earlier Windows versions to look for !INCLUDE files in either the directory below (versions earlier than 2.5) or above (versions 2.5 and 2.5a) the directory where the documentation says it looks.
• Fixed a bug which caused surname ``JAMES'' to appear before surname ``JAME'' in the index.
• Fixed a bug in the that was causing links between sources to fail.
• Fixed an omission from the output templates that was causing sources associated with family events not to appear in the HTML output.
• Added some documentation about international character sets, and revised some other parts of the documentation.

• Fixed -w 0 option so it works instead of crashing the program.
• Added a trailer line to the GENDEX files to help in detecting truncation.
• Added Kagi Shareware REGISTER.EXE program to provide additional ways to pay the registration fee under Windows. This should make it feasible and convenient for non-US users to pay by credit card.

• Revamped the scheme for assigning individuals to subdirectories and files within subdirectories. The new scheme calculates the particular directory and file in which to put an individual from the individual's cross-reference ID, so the same individual will always end up in the same directory and file as long as the same number of directories and number of files per directory are used. A new option (-D n) was added to allow the user to specify the number of directories to be used. This should make it possible to link to individual pages from external documents, and have these links remain valid when the GEDCOM is re-processed, even if individuals have been added to the GEDCOM since the first run.
• Added the following feature to aid in eliding information about living persons: If an 0 INDI record for an individual contains a field that begins 1 NOTE !LIVING, then all personal data is deleted from that individual's page and the only information that is output is the text of the note.
• Eliminated large array allocation that was effectively limiting the number of individuals that could be processed to 16384 under Windows.
• Changed the option syntax for dumping compiled-in templates so that it can actually be used under Windows to dump templates to a file.
• Fixed a problem with empty surnames generating multiple entries in the surnames index.
• Fixed a problem under Windows, where files to be included in the HTML output were being looked for in the wrong directory.
• The GENDEX.txt index files now use christening date/place if no birth information is available, and burial date/place if no death information is available.

• Fixed bug that could cause infinite looping at end of file on some Unix systems, and caused weird syntax errors when 8-bit characters occurred in GEDCOM files under Windows.
• Fixed bug where the alternate index and surname template fields were interchanged in the GED2HTML.EXE dialog box under Windows.
• Windows executables are much smaller, and probably run a bit faster, due to the use of different compiler options.

• Introduced changes that cut memory usage in half, and also significantly boost performance.

• Some progress printout was added to the Windows version, because people were mailing me telling me that the program had hung up, when in fact it was just taking a long time.

• GED2HTML is now being released as shareware. Please see here for more information.
• New documentation has been written in HTML. You're reading it.
• The DOS version of the program has been discontinued. Only the Windows version is in the current release. The DOS version was pretty useless for GEDCOM's of any interesting size, anyway.
• A true Windows user interface is now provided to make it easier and less confusing for most Windows users to run the program.
• Source records are now supported. Previous versions of the program would only include source information at level 1 within INDI records. Furthermore, full source structures were not supported. The Version 2.4 handles cross-referenced source records at level 0, as well as source structures within INDI, FAM, NOTE, and event structures at higher levels. The existence of source information is signalled in the output file by ``footnote markers'' that appear near the information to which they pertain. The footnote markers link to source information in separate HTML files. The chaining of source structures, as described in the GEDCOM 5.3 draft standard, is also supported, but it is not thoroughly tested since I do not have sample GEDCOMs that use this feature. At present, only source structures chained to other source records are handled. Chaining of source structures to event records, though allowed by the GEDCOM 5.3 draft standard, will result in an error message.
• Performance improvements have been made in the production of the output files, especially under Windows.
• OCCU, EDUC, and a variety of other tags giving information about an individual are now processed properly, and the information appears in the output files.
• Pedigree charts have been changed slightly to be a little more compact at depths of 4 or greater.
• PERSONS.html is now the name of the top-level index file, rather than INDEX.html. The latter was an unfortunate choice that conflicted with defaults built into many Web servers.
• Titles of individual pages now include birth and death dates.
• New template constructs have been added to cause the date of the run and the version number of GED2HTML to be inserted into the output.
• The Windows version of the program now creates its output files in a subdirectory HTML, rather than in the directory from which it was run.
• The hierarchical index algorithm was modified to try to reduce the frequency of index nodes with hardly any entries in them. The current scheme adjusts the width of the index nodes less than the specified maximum width, so that all the nodes at the same level of the index have close to the same number of entries. Under certain conditions the top-level index node can still end up with as few as two entries, but this can be worked around by adjusting the specified maximum width until better results are obtained.
• A few minor bugs were fixed that existed in the previous version of the program.

GED2HTML: Downloading the Program

• A Windows 95 version.
• A Windows 3.1 version.
• Various Unix versions.
• A Macintosh version.

Except for one of the Unix versions, which contains source code to GED2HTML version 2.4a, all the above distributions are binary executables only. Please note that I currently have no plans to distribute sources to any versions more recent than 2.4a. However, if you are a Unix user, you try the 2.4a source distribution and you send me the registration fee, I am typically willing to go to some trouble to try to provide you with a binary upgrade to the most recent version, assuming that I can get access to an ANSI C compiler on the type of platform you use. I maintain a collection of binaries of various versions of the program for various Unix platforms. If you don't see what you want at the downloading screen, it is best to mail me to find out whether I can supply an upgrade for your platform.

GED2HTML home page

GED2HTML: Downloading the Windows 3.1 Version

• Get the Windows 3.1 demo version.
• Get the Windows 3.1 full version (registered users only).

• wiz401x.exe (Info-ZIP WiZ for Windows 3.1: a very nice, free ZIP/UNZIP program, with a GUI. Handles long filenames! For more information about Info-ZIP, and for the most recent releases, see here.)

• tar.exe. (used to pack/unpack a tar archive, for uploading large numbers of files and directories to a Web provider) Note though, that this binary is a 16-bit binary which does not understand Windows 95 long filenames.

• WS-FTP may be of interest to you if you don't have a good FTP utility.

GED2HTML home page

GED2HTML: Downloading the Windows 95 Version

• Get the Windows 95 demo version.
• Get the Windows 95 full version (registered users only).

• wiz401xN.exe (Info-ZIP WiZ for Windows 95/NT: a very nice, free ZIP/UNZIP program, with a GUI. Handles long filenames! For more information about Info-ZIP, and for the most recent releases, see here.)

• tar.exe. (used to pack/unpack a tar archive, for uploading large numbers of files and directories to a Web provider) Note though, that this binary is a 16-bit binary which does not understand Windows 95 long filenames.

• WS-FTP may be of interest to you if you don't have a good FTP utility.

GED2HTML home page

GED2HTML: Downloading Unix Versions

The following can be downloaded by anyone.

• Get the generic current distribution, including documentation, but minus the binary executable program.
• Get the (old) GED2HTML v2.4a source distribution.
• Get the GED2HTML 3.1a binary for DEC Alpha OSF/1 (demo version)
• Get the GED2HTML 3.0b binary for FreeBSD 2.2 (demo version)
• Get the GED2HTML 3.1a binary for HP-9000 running HP-UX (demo version)
• Get the GED2HTML 3.0b binary for SGI IRIX 6.2 (demo version)
• Get the GED2HTML 3.1a binary for Linux ELF (demo version)
• Get the GED2HTML 3.1a binary for Solaris 2.5.1 (demo version)
• Get the GED2HTML 3.0b binary for SunOS 4.1.3 (demo version)

The following are currently available only to registered users.

• Get the GED2HTML 3.1a binary for Dec Alpha OSF/1 .
• Get the GED2HTML 3.0b binary for FreeBSD 2.2 .
• Get the GED2HTML 3.1a binary for HP9000 running HP-UX .
• Get the GED2HTML 3.1a binary for Solaris 2.5.1 .
• Get the GED2HTML 3.0b binary for SunOS 4.1.3 .
• Get the GED2HTML 3.0 binary for SGI IRIX 5.3 .
• Get the GED2HTML 3.1a binary for Linux ELF .
• Get the GED2HTML 3.0b binary for SGI IRIX 6.2
• Get the GED2HTML 2.5b binary for SCO SV_3.2.2 .

GED2HTML home page

GED2HTML: Running the Program

• Running the Windows 95 and Windows 3.1 versions.
• Running the Unix version.

Running the Windows Version of GED2HTML

Downloading and Unpacking the Distribution

Note that the InfoZIP "WiZ" program is distributed as a single file wiz401xN.exe which is a "self-extracting archive". To unpack it, you just put this file in an otherwise empty directory, and launch it, either by double-clicking on its name or icon under Windows Explorer, or else by typing its name at the MS-DOS prompt. It should unpack itself and create a number of files, including the application wiz.exe. Launching wiz.exe will bring up a screen that you can use to unzip GED2HTML. There are help files distributed with "WiZ" that you can read if it is not clear how to use it.

To unpack GED2HTML, launch your unzip program and specify the filename ged2html.zip as the file to be unpacked. Alternatively, you could try double-clicking directly on ged2html.zip and when the system asks you what application you would like to associate with files with extension .zip you can specify your unzip program. In either case, once GED2HTML is unpacked, you should have a number of files in the folder with the GED2HTML.ZIP. Among the files you now have are the following executables:

1. REGISTER.EXE
2. GED2HTML.EXE
3. G2H.EXE

The file GED2HTML.EXE is the Windows user interface for GED2HTML, and it is what you should use to launch the program. This user interface simply collects your options in a dialog box, and then starts G2H.EXE, which is the "back-end" program that does all the real work. Since (unlike previous versions of GED2HTML) all the options understood by G2H.EXE can now be accessed via the GED2HTML.EXE interface, there is probably no need for you ever to run G2H.EXE directly. However, please note that for proper operation, GED2HTML.EXE has to be able to find G2H.EXE, and thus either both must reside in the same directory or else you will have to modify the PATH setting in your AUTOEXEC.BAT file so that the directory where G2H.EXE resides is included in the PATH.

Running GED2HTML with the Default Options

As your GEDCOM is processed, you will see various progress messages output in the console window. First the GEDCOM is read, then the individuals are sorted and index files are output, then sources and notes files are output, then the individuals are resorted, and finally the individuals files are created. When processing has finished, you will see the message "Processing complete". Under Windows 95 you should press ENTER to close the console window. Under Windows 31 the word FINISHED will appear in the lower left-hand corner of the window, and you will have to close the console window using the system menu.

By default, the HTML files produced by GED2HTML are placed in a subdirectory "HTML" of the directory from which it was started. You may peruse the files with your Web browser to verify that they are OK. Good starting points are the files "PERSONS.HTM" and "SURNAMES.HTM" (under Windows 95, "persons.html" and "surnames.html").

Exactly how long it will take to process your GEDCOM is primarily dependent on whether you have enough RAM on your system for the size GEDCOM you are attempting to process. Roughly speaking, this generally amounts to about one megabyte of RAM per thousand individuals in your GEDCOM. Thus, a 10,000-individual GEDCOM could be processed comfortably in 10MB of RAM. In this case, the program will spend most of its time generating the output files, rather than reading the input data. As the ratio of individuals to RAM approaches one megabyte of RAM per two thousand individuals, the program will become slower and slower at reading in the GEDCOM file, and will make extensive use of the disk. In this case, during certain phases of program execution where the individuals are sorted, it may appear that the program is "hung". Most likely it isn't; rather, it is just busy trying to shuffle your data back and forth between disk and RAM. It is probably not feasible to process a GEDCOM if there are more than three thousand individuals per megabyte of RAM.

Customizing GED2HTML Output

GED2HTML home page

Running the Unix Version of GED2HTML

Downloading and Unpacking the Distribution

If what you really wanted was source, please note that the only source version that I am currently distributing is GED2HTML version 2.4a. If you want to play with source code to this old version, go ahead and download it, but as I am no longer developing or supporting this version, you are pretty much on your own. You will need an ANSI C compiler (such as GCC) and a "make" utility to compile the program. Old non-ANSI C compilers will not work, sorry. Also, you may have to do various kinds of tweaking to the C preprocessor #define's or the Makefile to get the source to compile on your particular system. Many times this is due to lack of ANSI compliance of the compiler being used.

The generic distribution of GED2HTML comes in the form of a gzipped tar file, so you will need "gunzip" and "tar" (standard tools on most Unices) to unpack the distribution. After downloading, you should have a file "g2hdocs.tar.gz". First, uncompress it using the command:

The GED2HTML executables for the various platforms are distributed as gzipped binary files. For example, after downloading the executable for a SparcStation running Solaris 2.4, you might have a file "ged2html_v2.5b_solaris5.4.gz". Put it in the same directory where you unpacked the current distribution and uncompress it using the commands:

Running GED2HTML with the Default Options

In keeping with the Unix tradition of terse programs, the Unix version of GED2HTML does not print many comforting messages as it reads your data and writes the output files. The only message printed is a single line output after GED2HTML has finished reading your GEDCOM, but before it begins creating the HTML files. This message reports the number of lines of GEDCOM that were processed, and how many of each different kind of record (individual, family, note, etc.) were encountered.

By default, the HTML files produced by the Unix version of GED2HTML are placed in the current directory. You may peruse the files with your Web browser to verify that they are OK. Good starting points are the files "persons.html" and "surnames.html".

Exactly how long it will take to process your GEDCOM is primarily dependent on whether you have enough RAM on your system for the size GEDCOM you are attempting to process. Roughly speaking, this generally amounts to about one megabyte of RAM per thousand individuals in your GEDCOM. Thus, a 10,000-individual GEDCOM could be processed comfortably in 10MB of RAM. In this case, the program will spend most of its time generating the output files, rather than reading the input data. As the ratio of individuals to RAM approaches one megabyte of RAM per two thousand individuals, the program will become slower and slower at reading in the GEDCOM file, and will make extensive use of the disk. It is probably not feasible to process a GEDCOM if there are more than three thousand individuals per megabyte of RAM.

Customizing GED2HTML Output

GED2HTML home page

Output Files Produced by GED2HTML

The following is a description of the various output files and directories produced by GED2HTML:

• persons.html (PERSONS.HTM under Windows 3.1)

  This file is the top-level file of the hierarchical index of individuals. It can be used as an entry point to the database. If you specified a flat index, then entries for all the individuals appear in this file in alphabetical order. Otherwise, this file contains links to sub-index containing ranges of names, which point ultimately to the individual data pages.

• indxxxx.html (INDxxxx.HTM under Windows 3.1)

  These files, which are present if you elected to use a hierarchical index of individuals, contain index nodes below the top level.

• index

  If you elected to use subdirectories, this directory is created to hold the persons index files.

• surnames.html (SURNAMES.HTM under Windows 3.1)

  This file contains a list of all the surnames in the database, with links into the lowest-level index pages. This file can also be used as an entry point to the database.

• surxxxx.html (SURxxxx.HTM under Windows 3.1)

  These files, which are present if you selected a maximum number of surnames per file, contain a "chunk" of the surnames index.

• surnames

  If you elected to use subdirectories, and specified a maximum number of surnames per file, then this directory is created to hold the surnames index files.

• sources.html (SOURCES.HTM under Windows 3.1)

  This file contains all the level zero source records from the database. Source links from the individual data pages point here.

• souxxxx.html (SOUxxxx.HTM under Windows 3.1)

  These files, which are present if you selected a maximum number of sources per file, contain a "chunk" of the level zero sources files.

• sources

  If you elected to use subdirectories, and specified a maximum number of sources per file, then this directory is created to hold the sources files.

• notes.html (NOTES.HTM under Windows 3.1)

  This file contains all the level zero notes information from the database. Source links from the individual data pages point here.

• notxxxx.html (NOTxxxx.HTM under Windows 3.1)

  These files, which are present if you selected a maximum number of notes per file, contain a "chunk" of the level zero notes files.

• notes

  If you elected to use subdirectories, and specified a maximum number of notes per file, then this directory is created to hold the notes files.

• gendex.txt (GENDEX.TXT under Windows 3.1)

  This file contains a list of all the individuals in the database, together with birth and death dates and places, but no lineage or other information. It is output in a special format to enable it to be processed by automatic indexing programs. See here for more information on an indexing service I am running.

• gxxxxx.html (Gxxxxx.HTM under Windows 3.1)

  These files contain the actual data on individuals. The number of individuals per file depends on the default settings and the command-line options you chose.

• fxxxxx.html (Fxxxxx.HTM under Windows 3.1)

  If you elected the family group sheet form of output, then these files contain family group data. The number of families per file depends on the default settings and the command-line options you chose.

• dxxxxx/

  If you elected to use subdirectories, then these directories are created to hold the individual data files.

Uploading GED2HTML Output to your Web Provider

The output of GED2HTML on a typical GEDCOM can be a very large number (thousands) of files and directories. Uploading each of these files individually to a Web provider would be an incredibly time-consuming and tedious task that is to be avoided at all costs. Similarly, performing any kind of individual editing on every file output by GED2HTML is also generally not feasible. About the only thing that it might be feasible to do (and sometimes necessary) is to systematically rename all the output files from GED2HTML, for example to change the filename extensions from .HTM to .HTML. Even this is to be avoided if at all possible.

To avoid having to upload individual files, the following general strategy is applied to get the files (and directories) from your system to your Web provider's system:

1. First, an archiver is used, to package up all the files and directories output by GED2HTML into a single "archive" file. Examples of archivers are various versions of ZIP, as well as the Unix program "tar".

2. Next, the archive file is uploaded to your Web provider's system, typically using FTP, but perhaps Kermit or Zmodem. Usually, archive files are binary data, so when using FTP it is important to select "binary" or "image" mode when uploading them.

3. Finally, the archive file is unpacked into place on your Web provider's system. This requires that an "unarchiving" program, complementary to the one you used to create the archive, be available on your Web provider's system, and that also you have sufficient access to your Web provider's system (typically a "shell account") to be able to run the unarchiver on that system.

One big thing that can go wrong with the above strategy is that you might not have shell access to your Web provider's system. In that case, all bets are off, and you will have to check with your Web provider's technical support staff to find out what might be the best way to get the GED2HTML output files and directories from your personal computer to the Web provider's system. Often the best strategy in this case is to use a good FTP client such as WS-FTP that is capable of uploading multiple files without manual intervention.

What Archiver to Use?

Note that when unpacking a ZIP archive with a program such as PKUNZIP, it may be necessary to tell the program to preserve the directories (folder) organization the files originally had when they were created by GED2HTML. When using PKUNZIP to unpack the archive, this is done by giving the "-d" parameter on the command line. When using WinZip to unpack the archive, the "Use Folder Names" box should be checked to do the same thing.

Another alternative is the classic unix "tar" archiver. Many Web providers are Unix-based systems, and essentially every Unix system has the "tar" program available, so using "tar" to create the archive is often a viable option. You can download a TAR.EXE for use under DOS or Windows from here. (Note that this version of TAR.EXE is a DOS program that doesn't understand Windows 95 long filenames. There may be more up-to-date versions available on the 'net, but I haven't looked recently.)

Use the DOS command

Can't Use Subdirectories

You should be aware that, with a GEDCOM of any significant size, GED2HTML will produce a great many output files. One reason why GED2HTML uses subdirectories in the first place is that it can be somewhat inconvenient to manipulate a directory containing several thousand files. In addition, under Windows accessing such directories becomes very slow. If you ask GED2HTML to create a "flat" file structure, be aware that it could take substantially longer to create your HTML files, and that dealing with the resulting directory might be a bit cumbersome.

Upper-case Filenames and Lower-case Links

One way to get around this problem, should you encounter it, is to see if the uploading program or unarchiver you used has an option that allows you select whether DOS files are unpacked with upper-case or lower-case names. If so, that may be the fastest way out. If not, then GED2HTML is now fully configurable to handle this type of situation. If you find that files are ending up on your Web provider with all upper-case names, then set the "Case-fold-links" option of GED2HTML to "Upper" before processing your GEDCOM. This will cause GED2HTML to make all the links in the HTML output upper-case only, so that they will work properly once the whole batch of files arrives on your provider's system. If you find that files are ending up on your Web provider with all lower-case names, then set the "Case-fold-links" option of GED2HTML to "Lower". If both your system and your Web provider's system are case-sensitive systems, then setting "Case-fold-links" to "None" is probably the option for you. See here for more details on this, and other customization options provided by GED2HTML.

HTM versus HTML

When you create HTML files under Windows 3.1, all the files are created with a .HTM extension, because DOS only supports three-letter filename suffixes, and will truncate anything longer than that. When run under Windows 3.1, the default behavior of GED2HTML is to use a .HTM extension for all the hyperlinks internal to the output files, in order to be compatible with the .HTM extension with which the files are created.

When you upload files created under Windows 3.1 to your provider's system, everything will be fine as long as the HTTP (Web) server running on your provider's system is set up to recognize files ending in .HTM as HTML source code. The server passes this information along to your browser, which formats displays the information properly. However, not all HTTP servers are configured to recognize files ending in .HTM as HTML files. In this case, the server will tell your browser that the file is text, and it will not be properly displayed.

The simplest way out of this predicament is to ask for the cooperation of your Web service provider. Web servers generally have a "mime.types" configuration file, which lists mappings from filename extensions to MIME types. This information allows the server to determine what kind of information is in a file by looking at the extension. The server communicates this information to your browser when the file is retrieved, and the browser, in turn, uses the information to control how the file is displayed. Some servers lack an entry:

Although many Web service providers will make the configuration change described above, some providers will refuse to make the change and will tell you that you should change all filenames from .HTM to .HTML, perhaps using a special script that they provide. In this case, it will be necessary to reprocess and re-upload your data, so that all the internal links in each of the datafiles say .html instead of .htm. Under the Windows 3.1 version of GED2HTML, this can be done by putting the following in the "Additional Options:" field in the top-level dialog box:

I have also been told about a utility called "MultiRen", which is a Multiple File Rename utility. A GED2HTML user writes:

I discovered a neat Multiple File Rename utility, MultiRen, a great idea for those of us that use your GED2HTML for generating multiple databases, so we can give the g0000... and ind00... files different names (g12xx and ind12xx for instance) for each database. [I've been doing this by hand, and editing the html with a global find & replace utility]
> You can find it on p. 269 of the June 9th, '98 issue of PC Magazine and
> http://www.pcmag.com (at the home page click on downloads) or
> ftp.zdnet.com. The full source code is also available from
> http://www.pcmag.com.

GED2HTML: Customizing the Output

• Customizing the Windows 95 and Windows 3.1 versions.
• Customizing the Unix version.

GED2HTML home page

Customizing GED2HTML Output under Windows

When GED2HTML is launched, the dialog box that appears contains blanks for "GEDCOM File" and "Options File". There is a button group entitled "Option Editing", containing buttons "Load", "Edit", and "Save". Finally, there is a field entitled "Additional Options", and a field entitled "Options Summary". (The latter field is read-only.) To cause the program to do anything interesting at all, you at least have to enter the name of the GEDCOM File to be processed in the "GEDCOM File" field. The other fields and buttons are used to load, edit and save options sets that control how your GEDCOM is processed. When you are satisfied with the options set you have selected, click on "OK" to initiate processing of your GEDCOM.

To preload an options set saved in a previous run of GED2HTML, enter the name of the saved options set in the "Options File" field, and then click on "Load". The previously saved options will be read in and used to initialize the various fields of the dialog box. To save the currently selected options, click on "Save". You will be prompted with a "Save As" box for selecting the name of the file to which to save the options set.

To make changes to the current options set, click on "Edit". This will bring up a second dialog box containing several more fields, entitled "Output Program", "Mail-to address", "Home page URL", and "Target Directory". These are used as described below. When you are satsfied with the options you have selected, click on "OK" to return to the top-level dialog box. Clicking on "Cancel" returns you to the top-level dialog box after abandoning any changes you have made.

The customizable fields appearing in the dialog box are listed and explained below. Note that there are many other options you can select that do not have their own fields in the dialog box. Those options are selected using the "Additional Options" field, as described here.

Output Program:

This field is used to enter the name of an output program to substitute for the built-in program. For more on output programming, see here.

Mail-to address:

If desired, enter your E-mail address in this field. GED2HTML will automatically place a "mailto" link at the bottom of the "top-level" persons and surnames index pages, to enable people viewing your pages to send you E-mail in a convenient way. It is highly recommended that you use this option, because I get lots of E-mail from people who are looking at GED2HTML pages created without "mailto" links, and who would like to contact the creator of the page with valuable additional information or corrections, but can't figure out how to do it.

Home page URL:

If desired, enter the URL of your main "Welcome" page here. GED2HTML will automatically place a "home" link at the bottom of each page of output, to enable people viewing your pages to navigate back to your home page. Use of this option is also highly recommended, because many people aren't familiar enough with the Web to figure out how to find a "home" page unless they have a specific link to it.

Target Directory:

By default, GED2HTML places its output in a subdirectory "HTML" of the current directory. If you wish it to place its output somewhere else, put the name of that directory in this field. GED2HTML will attempt to create this directory if it doesn't already exist.

From the second-level dialog box, clicking on "More Options" will bring up yet another dialog box with lots of blanks and buttons. Below a brief description is given of each. After you are satisfied with the options you have selected, click on "OK" to return to the previous dialog box. Clicking on "CANCEL" returns you to the previous dialog box after abandoning any changes you made.

Individuals per file:

A number entered in this box determines the number of individuals GED2HTML will try to put in each of the individual data files it creates. Putting several individuals in a single file tends to save disk space on many systems. The default value is 10. To force GED2HTML to put exactly one individual per file, enter 0 in this field.

NOTE: If "Stable filenames" is selected (the default), then GED2HTML treats a positive value entered for "Individuals per file" as a suggested target value. It does not necessarily guarantee to put exactly the specified number of individuals in each file. If you must have exactly the specified number of individuals in each file, then turn off "Stable filenames". To understand more about how GED2HTML organizes information into various files, see here.

Files per directory:

A number entered in this box determines the number of individual data files GED2HTML will put in a single subdirectory. The default value is 100. If 0 is entered in this box, then GED2HTML will not use any subdirectories. Instead, it will create a "flat" structure in which all output files reside in the same directory.

CAUTION: Accessing directories with thousands of files in them is very slow under Windows, and especially under Windows 3.1. You are better off using subdirectories if at all possible.

Number of directories:

A number entered in this box forces GED2HTML to use a fixed number of subdirectories to contain the individual data files. The default value is 0, which permits GED2HTML to use as many directories as it sees fit. Note that a nonzero value entered in this box causes any value entered in "Individuals per file" to be ignored, and GED2HTML will put as many individuals as necessary in each file in order to output all the individuals using the specified number of directories and files per directory.

Sources per file:

For GEDCOMs containing many source records, putting all the sources in a single HTML file can produce a file that is too large to be downloaded conveniently over the Web. Entering a nonzero value in this field causes GED2HTML to output sources to multiple files, with the total number of sources output in any one file limited to the specified value. The default value is 0, which means put all sources in a single sources file.

Notes per file:

For GEDCOMs containing many notes records, putting all the notes in a single HTML file can produce a file that is too large to be downloaded conveniently over the Web. Entering a nonzero value in this field causes GED2HTML to output notes to multiple files, with the total number of notes output in any one file limited to the specified value. The default value is 0, which means put all notes in a single notes file.

Pedigree depth:

The value entered in this field controls the number of generations of ancestors that appear in the pedigree charts output in each individual data page. The default value is 2. Entering a value of 0 turns off the production of pedigree charts.

Indiv. index width:

The value entered in this field controls the maximum number of entries in each page of the hierarchical persons index. The default value is 28, which means that each index page will contain links either up to 28 individual data pages, or up to 28 "lower-level" index pages. In general, the more entries per page, the fewer "levels" of index are necessary to index a given number of individuals. Entering 0 in this field turns off the hierarchical index feature, causing a "flat" index to be created in which all individuals appear in a single index page.

Note that GED2HTML does not always put the maximum number of individuals in an index page. Rather, it tries to adjust the number of individuals in an index page to avoid producing lots of "widow" pages that contain very few entries. It generally succeeds at this, except that it is sometimes the case that the top-level index page has only two entries in it. If it occurs, this situation can generally be avoided by increasing the index width somewhat.

Surname index width:

For large GEDCOMs, putting all the surnames in a single surnames file can produce a file that is too large to download conveniently over the Web. Entering a nonzero value in this field causes GED2HTML to create a multiple-file surname index, in which the number of surnames in any given file is limited to the specified value. The default value is 0, which causes GED2HTML to put all the surnames in a single file.

Language:

The string entered in this field selects the (human) language that will be used to produce various components of the HTML output. For example, if "English" is entered in this field, or it is left blank, then the output will be in English. If, instead "French" is entered in this field, then the output will be in French. The currently available choices are "English", "French", "Danish", "Dutch", "German", "Italian", "Norwegian", "Swedish", and "Finnish".

For further information on the effect of changing the output language, see here.

Case fold links:

This group of three radio buttons selects certain processing to be performed on the URLs output in HTML anchors (hyper-links). If "Lower" is checked, then all URLs output by GED2HTML as part of HTML anchors are converted (folded) to lower case before being output. If "Upper" is checked, then all URLs are converted to upper case. If "None" is checked, then no conversion of any kind is performed. The default is "None".

The reason for this feature is to accomodate the ideosyncrasies of various systems and uploading software having to do what happens to MS-DOS-style upper-case-only filenames when the files are uploaded from a Windows system to a Web service provider's system. If your uploading software seems to create all files on the provider's system with lower-case names, then select "Lower", to make the hyper-links work properly once the files have been uploaded. If your uploading software creates all files on the provider's system with upper-case names, then select "Upper" instead. If you are using case-sensitive uploading software to upload from Windows 95 to a Unix or Windows 95 provider with a case-sensitive Web server, then "None" is probably the correct option to choose.

See here for additional discussion of the upper-case/lower-case issue.

Upper-case surnames:

Checking this box causes all surnames to be converted into upper case as the GEDCOM is read. The default is checked.

Output individuals:

Checking this box enables the creation of the data pages for individuals. The default is checked.

Output index:

Checking this box enables the creation of the persons and surnames indexes. The default is checked.

Output GENDEX:

Checking this box enables the creation of the "gendex.txt" index file, which can be used by the GENDEX genealogical index to centrally index your data so that others can find it more easily. The default is checked.

Output sources:

Checking this box enables the creation of the sources files. The default is checked.

Output notes:

Checking this box enables the creation of the notes files. The default is checked.

CONT means break:

If this box is checked, then notes records in the GEDCOM that are continued over several GEDCOM lines using the CONT tag will be rendered in the HTML output with a line break <BR> before each CONT line. Continuation lines that use the CONC tag are rendered without a line break. This seems to correspond to the spirit of what the GEDCOM standard has to say about the use of CONT and CONC, however the output of some genealogy programs looks ugly this way. In such cases, unchecking this box makes CONT be rendered exactly like CONC; that is, without a line break. The default is checked.

Stable filenames:

Checking this box enables a feature that causes GED2HTML to use a "hash function" to calculate the directory and file in which the data for a given individual will appear, directly from the GEDCOM identifier for that individual. This has the advantage of making the mapping from individuals to directory/file pairs "stable" under additions to and deletions from the GEDCOM. This means that if you process your GEDCOM once, then add some new individuals to it and process your GEDCOM again, the second time all the individuals that were there the previous time end up in the exact same place in the output file as they did the first time. This feature can be advantageous for linking from external documents into the HTML tree output by GED2HTML. See here for more details. The default is to use this feature.

The disadvantages of checking "Stable filenames" are: (1) GED2HTML has less control over exactly how many individuals will end up in any given file; (2) the hash function randomizes the individuals so that a particular file will generally contain a number of completely unrelated individuals, rather than a group of individuals with the same surname.

The "Additional Options" Field

The other type of thing you can put in the "Additional Options" field are initializations for variables for the output interpreter. These initializations can be used to set existing options, or, in combination with modifications to the output program, to create new options. To cause the output interpreter variable "FOO" to be initialized with string value "BAR", you would put

Order of Options Processing

1. When GED2HTML.EXE starts, predefined default values are set for all the options.

2. Options settings are made by the user in the GED2HTML.EXE dialog box. These options can be saved by the user in a ".INI" file, and loaded back into the dialog box during a later run. Or, the ".INI" file can be edited directly if desired.

3. When the user clicks on "OK" in the GED2HTML.EXE dialog box to initiate GEDCOM processing, any options that were changed from the default values are output to the temporary file G2HOPTS.TMP. This file is used to communicate the changed options to the G2H.EXE program, which then starts.

4. G2H.EXE reads options settings from the file G2HOPTS.TMP.

5. G2H.EXE processes any settings the user might have made in the "Additional Options" field of the GED2HTML.EXE dialog box.

6. If an assignment has been made to the OUTPUT_PROGRAM option variable in any of the preceding steps, then the specified output program is located and compiled. Otherwise, the built-in standard output program is used.

7. G2H.EXE executes the procedure do_initialize in the output program. This function can be used to override options settings specified by the user using the dialog box.

8. G2H.EXE reads the GEDCOM file and produces output.

GED2HTML home page

Customizing GED2HTML Output under Unix

GED2HTML understands command-line arguments according to the following "Unix man page style" synopsis:

• The -H argument causes GED2HTML to print a brief message listing the available arguments.

• The -v option causes GED2HTML to print out its version number and copyright information.

• The -D option takes a single argument, which has the form "VARIABLE=VALUE", where VARIABLE is the name of an output interpreter variable to be initialized, and VALUE is an integer or string value to which it is to be initialized. If the VALUE starts with a digit, then it is regarded as an integer, otherwise it is regarded as a string. If the VALUE starts with a double quote ("), then it is interpreted as a string. In this case, the value must also end with a double quote, and the intervening characters are the characters in the string.

• The -f option takes a single argument, which is interpreted as the name of an options file. The options template file must be in the format of an GED2HTML output program (see here for more details) containing the definition of a single procedure, "set_options", whose purpose is to assign initial values to variables of the output interpreter that control GED2HTML processing. Any settings in the options file override defaults, but can themselves be overridden by initializations specified on the command line using the "-D" option, or by statements in the procedure "do_initialize" in the output program.

  The following is a simple example of an options file.

  define set_options() { set LANGUAGE to "French" set INDIVIDUALS_PER_FILE to 20 }

• The -t option takes a single argument. If the argument is '-', then GED2HTML dumps the source code for its built-in output program to the standard output. Otherwise, the argument is interpreted as a file name and the output program is dumped to that file. This option is used for obtaining the exact source code to the built-in output program, so that it can be used as a starting point for customizations. See here for information on output programs.

Nearly all the processing options that can be selected in a GED2HTML run are accessed by initializing certain variables of the output interpreter to have certain values. Initialization of output interpreter variables can be accomplished in three different ways:

1. By using the -D command line option to initialize the variables.
2. By using the -f command line option to select an options file. The "set_options" procedure in the options file is executed before any other processing occurs, for the purpose of initializing output interpreter variables.
3. By adding code to the procedure "do_initialize" in the output program, to perform the desired initializations.

For a list of all the output interpreter variables that can be initialized to select processing options, see here.

Order of Options Processing

1. When GED2HTML starts, predefined default values are set for all the options.

2. If an options file has been specified using the "-f" command line flag, then this file is read and compiled by the GED2HTML output language compiler. Then, the procedure "set_options" in this file is executed by the GED2HTML output language interpreter.

3. GED2HTML processes any additional options the user might have specified using the "-D" command line flag. Any such additional options settings override those from steps (1) and (2).

4. If an assignment has been made to the OUTPUT_PROGRAM option variable in step (2) or (3), then the specified output program is located and compiled. Otherwise, the built-in standard output program is used.

5. GED2HTML executes the procedure do_initialize in the output program. Any options settings made in this procedure will override those made in previous steps.

6. GED2HTML reads the GEDCOM file and produces output.

GED2HTML home page

Modifying the GED2HTML Output Program

A copy of the standard GED2HTML output program is provided with the GED2HTML distribution as file "standard.g2h". This output program was preloaded into GED2HTML when it was compiled, and it is the one that is used unless you explicitly supply another. If you are happy with the output produced by the default program, there is no reason for you to change it. Note that GED2HTML supports a large number of options that can be used to perform the most common customizations. However, if you wish to modify the format of the output files in some way that is not supported by any of the options, you can customize the output template to your own taste, and then specify that GED2HTML should use your template instead of the built-in one.

• Under Windows, this is accomplished by entering the name of the output program in the "Output Program" field of the second-level dialog box.

• Under Unix, you specify the name of the template file by using the "-D" command line argument to initialize the variable "OUTPUT_PROGRAM" to be the name of the file containing the output program. For example: ged2html -D OUTPUT_PROGRAM=myprog.g2h myged.ged specifies that "myprog.g2h" is to be substituted for the preloaded output program.

If you want to create your own output program, go ahead. You can't hurt anything. Use the standard output program as a starting point. GED2HTML reads your output program when it starts and reports on errors before attempting to process your GEDCOM. This means that, unlike earlier versions, it is no longer possible to "crash" GED2HTML by supplying an incorrect output program, and consequently template programming is pretty much like programming in a standard programming language. You can edit the output program using, e.g. the DOS "EDIT" program or the "Wordpad" program supplied with Windows 95. It is probably best not to use a word processor to edit the output program, because word processors typically feel free to change all sorts of things like spacing and special characters in the document being edited, which will cause your edited program not to be accepted by GED2HTML.

For full details on the template programming language, see here.

GED2HTML home page

The GED2HTML Output Language

Warning! The description of the output language given below is a fairly brief summary which is more or less in typical programming language manual style. I expect it to be understandable to a programmer, if not by itself then in conjunction with study of the standard output program, and possibly also some experimentation with the language. I have not made any sort of serious attempt to make it understandable to a non-programmer, nor am I likely to do so in the future.

Contents:

• Lexical Elements
• Variables, Types and Values
• Syntactic Elements
• Entry Points
• List of all Types and Associated Qualifiers
• List of all Special Variables

Lexical Elements

• Integer constants, which consist of any sequence of digits.

• String constants, which consist of a sequence of characters enclosed in double quotes ("). Special characters, such as newlines, tabs, form feeds, and double quotes, may be included in the string by using the following escape sequences, each of which consists of a backslash (\) followed by a single character:
  • \n stands for a newline.
  • \t stands for a tab.
  • \f stands for a form feed.
  • \" stands for a double quote.
  • \\ stands for a backslash.
• Identifiers, which consist of any sequence of upper- or lower-case letters, digits, or underscore (_), which begins with an upper- or lower-case letter or underscore.

• Keywords, which are those in the following list: debug, define, do, else, elseif, end, for, if, in, include, local, print, set, then, to, while.

• Comments, which begin with a # character, and continue to the end of the line.

• Arithmetic operators, + - * / %.

• Logical operators, & | ~.

• Relational operators, = < > <= >=.

• Concatenation operator, ^.

• Delimiters, ( ) [ ] { } ; . ,

Variables, Types and Values

• Integer values.
• String values.
• Individual values.
• Family values.
• Submitter values.
• Note values.
• Source values.
• Source citation values.
• Source data values.
• Repository values.
• Repository citation values.
• Change information values.
• Header values.
• Multimedia values.
• Name values.
• Attribute values.
• Event values.
• Place values.
• REFN values.
• Text values.
• Persons index values.
• Surnames index values.
• Ordinance values.
• Address values.
• Date values.

Each variable is either global, or else it is local to a particular procedure. Whether a variable is local as opposed to global depends on whether the procedure currently being executed contains a local declaration for that particular variable at the beginning of the procedure. The values of local variables persist only as long as the activation of the procedure in which they were declared. The value of a global variable persists either until GED2HTML exits, or else a new value is assigned to that variable.

Some global variables are special, in the sense that they are connected to the internal processing of GED2HTML. Certain special variables have the property that reading their value returns certain information about the current state of GED2HTML. Other special variables have the propery that assignments to them modifies certain parameters that control the processing of GED2HTML. Nearly all the GED2HTML processing options can be set by assigning to one of these special variables. For a list of all the special variables and their meanings, see here.

An attempt to access a variable that is not special and has never been assigned a value will yield a particular default value, usually corresponding to 0 or "false". Except during the options initialization phases that occur before GEDCOM processing starts, an attempt to assign a value to a global variable that does not already exist will elicit a warning message from the GED2HTML output interpreter. Usually this situation would occur if there was a missing local declaration for the indicated variable.

Syntactic Elements

Definitions

define <identifier> <formals> <locals> { <statements> }

local id1 id2 id3 ... idn

Statements

Empty statement:

A blank can appear whereever a statement is syntactically required. Executing the empty statement has no effect.

Call statement:

A call statement has the form:

<identifier> <actuals> ;

The <identifer> is the name of the procedure to be called. The <actuals> is a space-separated list of "atomic" expressions (any expression can be made into an atomic expression by enclosing it in parentheses). Executing a call statement causes the actual parameter expressions to be evaluated, and then the named procedure is invoked with the resulting values as the actual parameters.

Print statement:

A print statement has the form:

print <expressions> ;

or the form

print <expressions> ,

The <expressions> are a space-separated list of "atomic" expressions (any expression can be made into an atomic expression by enclosing it in parentheses). To execute a print statement, the expressions are evaluated, and the resulting values are output into the currently active output file, without any intervening spaces in the output. In the first form of the print statement, which ends with a semicolon, a newline is printed after the values of all the expressions have been printed. In the second form, no newline is printed.

Debug statement:

The debug statement is identical in form to the print statement. The only difference between the two is that the output from the debug statement is printed on the console (standard error), instead of the the current output file, as is the case with the print statement.

Assignment statement:

The assignment statement has the form:

set <identifier> to <expression>

Execution of an assignment statement proceeds by first evaluating the <expression>, and then assigning the resulting value to the variable <identifier>.

If statement:

The if statement has one of the forms:

if <expression> then <statements> end

if <expression> then <statements> else <statements>end

if <expression> then <statements>
elseif <expression> then <statements>
elseif <expression> then <statements>
...
else <statements> end

An if statement is executed by first evaluating the <expression> and interpreting the result as either "true" or "false". How the result of evaluation is interpreted depends on the type of value produced. If the value is an integer value, then a value of 0 is interpreted as "false" and a nonzero value is interpreted as "true". If the value is a string value, then a null value, or an empty string, is interpreted as "false", and other values are interpreted as true. If the value is any other type of value, then a null value is interpreted as "false" and a non-null value is interpreted as "true".

The truth value of the initial expression is used to control which of the alternatives is executed, in the usual way.

While statement:

The while statement has the form:

while <expression> do <statements> end

This statement is executed as follows: the <expression> and interpreting it as either "true" or "false" as in the case of the if statement. If the expression evaluates to "true", the <statements> are executed and the whole process repeats. If the expression evaluates to "false", execution of the statement terminates.

For statement:

The for statement has the form:

for <identifier> in <expression> do <statements> end

Execution proceeds as follows. First, the <expression> is evaluated. If the resulting value is null, then the statement terminates immediately. Otherwise, the value is assigned to the control variable <identifier> and the <statements> are executed. Upon completion, the qualifier "next" is applied to the value of the control variable from the preceding iteration. If the resulting value is non-null, then it is assigned to the control variable, the <statements> are executed, etc. Execution terminates when application of the "next" qualifier to the previous value of the control variable yields a null value.

Include statement:

The include statement has the form:

include <expression>

The expression is evaluated. The resulting value, which must be a string value, is interpreted as the name of a file. The file is opened, and its contents are inserted into the current output stream.

Expressions

Numerals:

A numeral, standing by itself, is an expression, which evaluates to the integer represented by the numeral.

Strings:

A string constant, standing by itself, is an expression, which evaluates to the corresponding string value.

Variables:

A variable, standing by itself, is an expression. Variables can be either simple variables, which are single identifiers, or can have a more elaborate structure, explained below.

Parenthesized expression:

An expression enclosed in parentheses is also an expression. Parentheses are used to indicate grouping in the usual way.

Negated expression:

An expression preceded by a minus sign is also an expression, which evaluates to the negative of the value to which the constituent expression evaluates.

Not expression:

An expression preceded by a tilde (~) is also an expression, which evaluates to a truth value which is the logical negation of the truth value to which the constituent expression evaluates.

Plus expression:

If E1 and E2 are expressions, then E1 + E2 is also an expression. If E1 evaluates to integer value v1 and E2 evaluates to integer value v2, then E1 + E2 evaluates to the integer value v1 + v2, otherwise an error occurs.

Minus expression:

If E1 and E2 are expressions, then E1 - E2 is also an expression. If E1 evaluates to integer value v1 and E2 evaluates to integer value v2, then E1 - E2 evaluates to the integer value v1 - v2, otherwise an error occurs.

Times expression:

If E1 and E2 are expressions, then E1 * E2 is also an expression. If E1 evaluates to integer value v1 and E2 evaluates to integer value v2, then E1 * E2 evaluates to the integer value v1 * v2, otherwise an error occurs.

Quotient expression:

If E1 and E2 are expressions, then E1 / E2 is also an expression. If E1 evaluates to integer value v1 and E2 evaluates to integer value v2, then E1 / E2 evaluates to the integer value v1 / v2, otherwise an error occurs.

Remainder expression:

If E1 and E2 are expressions, then E1 % E2 is also an expression. If E1 evaluates to integer value v1 and E2 evaluates to integer value v2, then E1 % E2 evaluates to the remainder of dividing v1 by v2, otherwise an error occurs.

AND expression:

If E1 and E2 are expressions, then E1 & E2 is also an expression. If E1 evaluates to a truth value v1 and E2 evaluates to a truth value v2, then E1 & E2 evaluates to the logical conjunction of v1 and V2, otherwise an error occurs.

OR expression:

If E1 and E2 are expressions, then E1 / E2 is also an expression. If E1 evaluates to a truth value v1 and E2 evaluates to a truth value v2, then E1 | E2 evaluates to the logical disjunction of v1 and V2, otherwise an error occurs.

Concatenation expression:

If E1 and E2 are expressions, then E1 ^ E2 is also an expression. If E1 evaluates to a string value v1 and E2 evaluates to a string value v2, then E1 ^ E2 evaluates to the string value which is the concatenation of v1 and v2, otherwise an error occurs.

Equality test:

If E1 and E2 are expressions, then E1 = E2 is also an expression, which evaluates to "true" if E1 and E2 evaluate to equal values, and to "false" if E1 and E2 evalute to unequal values.

Comparison test:

If E1 and E2 are expressions, then E1 < E2, E1 > E2, E1 <= E2, and E1 >= E2 are also expressions which which evaluates to "true" if the indicated relationship holds between the value of E1 and that of E2.

Variables

Simple variables:

An identifier, standing by itself, is a variable, which evaluates to the most recent value assigned to that variable. If no value has yet been assigned to the variable, an error occurs.

Qualified variables:

A qualified variable is a variable, followed by a dot (.), followed by a qualifier, which is an identifier. The qualifier serves to select a particular attribute or component of the current value of the variable to which it is attached. For example, if i is a simple variable whose current value is an individual, then

i.mother

is a qualified variable whose value is the individual who is the mother of the individual denoted by i. Furthermore,

i.mother.name

evaluates to the name of the mother. Qualifier names are not sensitive to upper/lower-case distinctions. Thus

i.mother

and

i.MOTHER

mean the same thing.

Whether the application of a particular qualifier to a variable v is meaningful depends on the current value of v at the time the qualified variable is evaluated. For a list of all the currently supported qualifiers together with the types of values to which they apply, see here.

Subscripted variables:

A subscripted variable is a variable followed by an expression enclosed in square brackets. Evaluation of a subscripted variable proceeds first by evaluating the subscript (the expression within the brackets). If the subscript does not evaluate to an integer, then an error occurs. Otherwise, the variable to which the subscript is attached is evaluated, and then the "next" qualifier is repeatedly applied to the resulting value a number of times equal to the value of the subscript expression.

As a simple example, the subscripted variable

i[3]

can be regarded as an abbreviation for the qualified variable

i.next.next.next

Entry Points

do_initialize

This entry procedure is called just prior to processing the GEDCOM file. It can be used to initialize or modify the settings of options variables. For a detailed description of how GED2HTML options processing works, see here for the Windows version and here for the Unix version.

do_index

This entry procedure is called to create the contents of a single file in the index of persons. The procedure takes a single argument, which is an index value corresponding to the first index entry to be output. Subsequent entries to be output to the same file can be accessed by repeatedly applying the "next" qualifier, until a null value is obtained.

Each index entry can be either a leaf entry, which references a single individual, or a range entry, which references a range of individuals. Whether the entry is a leaf entry or a range entry can be determined by applying the "children" qualifier to the index node. If node is a leaf entry, then applying the "children" qualifier yields a null value, and if the node is a range entry, then apply the "children" qualifier yields a nonnull value. For a leaf entry, the referenced individual can be obtained by applying the "first" qualifier to the entry. For a range entry, the first and last individual in the specified range can be obtained by applying the "first" and "last" qualifiers, respectively, to the entry.

do_surnames

This entry procedure is called to create the contents of a single file in the index of surnames. The procedure takes a single argument, which is an index value corresponding to the first index entry to be output. Subsequent entries to be output to the same file can be accessed by repeatedly applying the "next" qualifier, until a null value is obtained.

Each index entry can be either a leaf entry, which references a single surname, or a range entry, which references a range of surnames. Whether the entry is a leaf entry or a range entry can be determined by applying the "children" qualifier to the index node. If node is a leaf entry, then applying the "children" qualifier yields a null value, and if the node is a range entry, then apply the "children" qualifier yields a nonnull value. For a leaf entry, the referenced surname can be obtained by applying the "first" qualifier to the entry. For a range entry, the first and last surname in the specified range can be obtained by applying the "first" and "last" qualifiers, respectively, to the entry.

do_individuals

This entry procedure is called to create the contents of an individual data file. The procedure takes a single argument, which is the first individual for which information is to be output into the file. Subsequent individuals to be output to the same file can be accessed in succession by repeatedly applying the "next" qualifier. When application of the "next" qualifier results in a null value, the end of the list of individuals has been reached.

do_families

This entry procedure is called to create the contents of a family data file. The procedure takes a single argument, which is the first family for which information is to be output into the file. Subsequent families to be output to the same file can be accessed in succession by repeatedly applying the "next" qualifier. When application of the "next" qualifier results in a null value, the end of the list of families has been reached.

do_sources

This entry procedure is called to create the contents of a sources file. The procedure takes a single argument, which is the first source for which information is to be output into the file. Subsequent sources to be output to the same file can be accessed in succession by repeatedly applying the "next" qualifier. When application of the "next" qualifier results in a null value, the end of the list of sources has been reached.

do_notes

This entry procedure is called to create the contents of a notes file. The procedure takes a single argument, which is the first note for which information is to be output into the file. Subsequent notes to be output to the same file can be accessed in succession by repeatedly applying the "next" qualifier. When application of the "next" qualifier results in a null value, the end of the list of notes has been reached.

do_gendex

This entry procedure is called to create the contents of a "gendex.txt" file. The procedure takes a single argument, which is the first individual for which an index entry is to be output. Subsequent individuals can be accessed in succession by repeatedly applying the "next" qualifier. When application of the "next" qualifier results in a null value, the end of the list of individuals has been reached.

As the "gendex.txt" file has to be in a particular format to be understandable by the GENDEX index server, it is strongly suggested that you use the standard code for this procedure.

List of all Types and Associated Qualifiers

Integer values:

No qualifiers can be applied to integer values.

String values:

first

Yields a string obtained by breaking the given string into "words" delimited by space characters, and extracting the first such word.

next

Yields a string obtained by deleting the first space-delimited word from the given string.

upper

Yields a string value obtained by converting the given string to upper case. The conversion is dependent on the particular locale that has been selected at the time the conversion is performed. NOTE: Locales are not supported by GED2HTML running under Windows 3.1.

lower

Yields a string value obtained by converting the giving string to lower case. The conversion is dependent on the particular locale that has been selected at the time the conversion is performed. NOTE: Locales are not supported by GED2HTML running under Windows 3.1.

Individual values:

Individual values correspond to individual records in the GEDCOM file.

name

Yields a name value containing the name of the individual.

names

Yields a name value which is the head of a list of names associated with the individual. Names after the first can be accessed from the first by repeatedly applying the "next" qualifier.

surname

Yields a string value representing the surname of the individual.

birth

Yields an event value representing the event of birth of the individual.

death

Yields an event value representing the event of death of the individual.

attributes

Yields an attribute value which is the head of a list of attributes associated with this individual. Attributes after the first can be accessed from the first by repeatedly applying the "next" qualifier.

ordinances

Yields an ordinance value which is the head of a list of LDS ordinances associated with this individual. Ordinances after the first can be accessed from the first by repeatedly applying the "next" qualifier.

events

Yields an event value which is the head of a list of events associated with this individual. Events after the first can be accessed from the first by repeatedly applying the "next" qualifier.

families

Yields a family value which is the head of a list of families in which this individual was a child. Families after the first can be accessed from the first by repeatedly applying the "next" qualifier.

mother

Yields an individual value corresponding to the WIFE in the first family in which this individual was a child.

father

Yields an individual value corresponding to the HUSB in the first family in which this individual was a child.

marriages

Yields a family value which is the head of a list of families in which this individual was a spouse. Families after the first can be accessed from the first by repeatedly applying the "next" qualifier.

submitters

Yields a submitter value which is the head of a list of submitters of information pertaining to this individual. Submitters after the first can be accessed from the first by repeatedly applying the "next" qualifier.

associations

This qualifier is not yet fully implemented.

aliases

Yields an individual value which is the head of a list of individuals thought to be the same person as the current individual. Aliases after the first can be accessed from the first by repeatedly applying the "next" qualifier.

anci

Yields a submitter value which is the head of a list of submitters who have an interest in the ancestors of the current individual. Submitters after the first can be accessed from the first by repeatedly applying the "next" qualifier.

desi

Yields a submitter value which is the head of a list of submitters who have an interest in the descendants of the current individual. Submitters after the first can be accessed from the first by repeatedly applying the "next" qualifier.

sources

Yields a source citation value which is the head of a list of source citations associated with this individual. Citations after the first can be accessed from the first by repeatedly applying the "next" qualifier.

objects

Yields a multimedia value which is the head of a list of multimedia objects associated with this individual. Objects after the first can be accessed from the first by repeatedly applying the "next" qualifier. Multimedia objects are not completely supported in this version of GED2HTML.

notes

Yields a note value which is the head of a list of notes associated with this individual. Notes after the first can be accessed from the first by repeatedly applying the "next" qualifier.

rfn

Yields an attribute value corresponding to the RFN (if any) of the individual.

rfn

Yields an attribute value corresponding to the permanent Record File Number (if any) of the individual.

afn

Yields an attribute value corresponding to the LDS Ancestral File Number (if any) of the individual.

refns

Yields a REFN value corresponding to the head of a list of user Reference Number structures associated with the individual. Additional REFN substructures can be accessed by repeatedly applying the "next" qualifier.

rin

Yields an attribute value corresponding to the automated record ID for this individual.

ismale

Yields an integer value which is nonzero if the individual is indicated as a male, and zero otherwise.

isfemale

Yields an integer value which is nonzero if the individual is indicated as a female, and zero otherwise.

living

Yields a note value which is nonnull if the individual record has a NOTE substructure that begins with !LIVING. In this case, the value is a string representing the entire NOTE.

xref

Yields a string value representing the cross-reference ID of the individual record.

title

Yields a string value representing the title of the individual, as given by the first TITL substructure.

url

Yields a string representing a URL (uniform resource locator) which, when output as part of an HTML anchor, will create a hyperlink to the individual in question.

next

Yields the next individual value in whatever list the current individual value happens to be a part of.

tagcode

Yields the string value "INDI", which is the GEDCOM tag name used for individual records.

tagname

Yields a translation of the word "Individual" into the currently selected output language.

Family values:

Family values correspond to family records in the GEDCOM file.

events

Yields an event value which is the head of a list of events associated with this family. Events after the first can be accessed from the first by repeatedly applying the "next" qualifier.

husband

Yields an individual value representing the husband in the family.

wife

Yields an individual value representing the wife in the family.

children

Yields an individual value which is the head of a list of children in this family. Children after the first can be accessed from the first by repeatedly applying the "next" qualifier.

notes

Yields a note value which is the head of a list of notes associated with this family. Notes after the first can be accessed from the first by repeatedly applying the "next" qualifier.

nchildren

Yields an attribute value which gives the number of children associated with this family.

attributes

Yields an attribute value which is the head of a list of attributes associated with this family. Attributes after the first can be accessed from the first by repeatedly applying the "next" qualifier.

ordinances

Yields an ordinance value which is the head of a list of LDS ordinances associated with this family. Ordinances after the first can be accessed from the first by repeatedly applying the "next" qualifier.

submitters

Yields a submitter value which is the head of a list of submitters of information pertaining to this family. Submitters after the first can be accessed from the first by repeatedly applying the "next" qualifier.

sources

Yields a source value which is the head of a list of sources associated with this family. Sources after the first can be accessed from the first by repeatedly applying the "next" qualifier.

refns

Yields a REFN value corresponding to the first user Reference Number structure (if any) associated with the individual. Additional REFN structures can be accessed by repeatedly applying the "next" qualifier.

rin

Yields an attribute value corresponding to the automated record ID for this family.

next

Yields the next family value in whatever list the current family value happens to be a part of.

url

Yields a string representing a URL (uniform resource locator) which, when output as part of an HTML anchor, will create a hyperlink to the family in question.

xref

Yields a string value representing the cross-reference ID of the family record.

tagcode

Yields the string value "FAM", which is the GEDCOM tag name used for family records.

tagname

Yields a translation of the word "Family" into the currently selected output language.

Submitter values:

Submitter values correspond to submitter records in the GEDCOM file.

name

Yields an attribute value giving the name of the submitter.

objects

Yields a multimedia value which is the head of a list of multimedia objects associated with this family. Objects after the first can be accessed from the first by repeatedly applying the "next" qualifier.

address

Yields an address value giving the address of the submitter.

phone

Yields an attribute value giving the phone number of the submitter.

rfn

Yields an attribute value corresponding to the permanent Record File Number (if any) of the submitter.

rin

Yields an attribute value corresponding to the automated record ID for this submitter.

refns

Yields a REFN value corresponding to the head of a list of user Reference Number structures associated with the submitter. Additional REFN substructures can be accessed by repeatedly applying the "next" qualifier.

next

Yields the next submitter value in whatever list the current submitter value happens to be a part of.

tagcode

Yields the string value "SUBM", which is the GEDCOM tag name used for submitter records.

tagname

Yields a translation of the word "Submitter" into the currently selected output language.

Note values:

Note values correspond to note records (level 0) or note structures (higher levels) in the GEDCOM file.

xref

Yields a string representing the cross-reference ID of the note record. If the note is at level 0, then this string value will be non-null. For notes at higher levels, this string value will be a null value.

serial

Yields an integer value ("serial number") that uniquely identifies the particular note record, and which can be used to create a hyperlink to the note.

url

Yields a string representing a URL (uniform resource locator) which, when output as part of an HTML anchor, will create a hyperlink to the note in question.

text

Yields a text value representing the text of the note.

sources

Yields a source citation value which is the head of a list of source citations for the note. Citations after the first can be accessed from the first by repeatedly applying the "next" qualifier.

refns

Yields a REFN value corresponding to the first REFN substructure (if any) of the note. Additional REFN substructures can be accessed by repeatedly applying the "next" qualifier.

rin

Yields an attribute value corresponding to the automated record ID for this note.

rfn

Yields an attribute value corresponding to the permanent Record File Number (if any) of the note.

next

Yields the next note value in whatever list the current note value happens to be a part of.

tagcode

Yields the string value "NOTE", which is the GEDCOM tag name used for note records.

tagname

Yields a translation of the word "Note" into the currently selected output language.

Source values:

Source values correspond to source records in the GEDCOM file.

xref

Yields a string representing the cross-reference ID of the source record.

serial

Yields an integer value ("serial number") that uniquely identifies the particular source record, and which can be used to create a hyperlink to it.

url

Yields a string representing a URL (uniform resource locator) which, when output as part of an HTML anchor, will create a hyperlink to the source in question.

data

Yields a source data value that contains information from any DATA substructure of the source record.

author

Yields a text value that contains information about the author of the source.

title

Yields a text value that contains information about the title of the source.

abbreviation

Yields an attribute value that contains a short title for the source.

publication

Yields a text value that contains publication facts for the source.

text

Yields a text value representing the source text.

repository

Yields a repository citation value indicating the repository where the source resides.

notes

Yields a note value which is the head of a list of notes associated with this source. Notes after the first can be accessed from the first by repeatedly applying the "next" qualifier.

refns

Yields a REFN value corresponding to the first REFN substructure (if any) of the source. Additional REFN substructures can be accessed by repeatedly applying the "next" qualifier.

rin

Yields an attribute value corresponding to the automated record ID for this source.

change

Yields a change information value giving information about the last change to the source record.

next

Yields the next source value in whatever list the current source value happens to be a part of.

tagcode

Yields the string value "SOUR", which is the GEDCOM tag name used for source records.

tagname

Yields a translation of the word "Source" into the currently selected output language.

Source citation values:

Source citation values correspond to source citations in the GEDCOM file.

source

Yields a source value corresonding to the cited source.

page

Yields an attribute value that contains the page number(s) from the cited source.

event

Yields an attribute value identifying the event to which the source citation pertains.

date

Yields a source data value that contains data from the cited source.

quay

Yields an attribute value describing the "quality" of the cited source.

notes

Yields a note value which is the head of a list of notes associated with this source citation. Notes after the first can be accessed from the first by repeatedly applying the "next" qualifier.

description

Yields a text value describing the cited source.

abbreviation

Yields an attribute value giving an abbreviated title of the cited source.

title

Yields an text value giving the title of the cited source.

texts

Yields a text value which is the head of a list of texts from this source. Texts after the first can be accessed from the first by repeatedly applying the "next" qualifier.

serial

Yields an integer value ("serial number") that uniquely identifies the particular citation, and which can be used to create a hyperlink to it.

next

Yields the next source value in whatever list the current source value happens to be a part of.

tagcode

Yields the string value "SOUR", which is the GEDCOM tag name used for source records.

tagname

Yields a translation of the word "Source" into the currently selected output language.

Source data values:

Source data values capture information present in a DATA substructure of a source record or source citation structure.

events

Yields an event value which is the head of a list of events associated with this source data substructure. Events after the first can be accessed from the first by repeatedly applying the "next" qualifier.

agency

Yields an attribute value giving the agency responsible for the source data.

date

Yields a date value giving the "entry recording date" for the source citation.

notes

Yields a note value which is the head of a list of notes associated with this data. Notes after the first can be accessed from the first by repeatedly applying the "next" qualifier.

texts

Yields a text value which is the head of a list of texts from this source. Texts after the first can be accessed from the first by repeatedly applying the "next" qualifier.

next

Yields the next source value in whatever list the current source value happens to be a part of.

tagcode

Yields the string value "DATA", which is the GEDCOM tag name used for source records.

tagname

Yields a translation of the word "Data" into the currently selected output language.

Repository values:

Repository values correspond to repository records in the GEDCOM file.

name

Yields an attribute value giving the name of the repository.

address

Yields an address value giving the address of the repository.

phone

Yields an attribute value giving the telephone number for the repository.

notes

Yields a note value which is the head of a list of notes associated with this repository. Notes after the first can be accessed from the first by repeatedly applying the "next" qualifier.

refns

Yields a REFN value corresponding to the first REFN substructure (if any) of the repository. Additional REFN substructures can be accessed by repeatedly applying the "next" qualifier.

rin

Yields an attribute value corresponding to the automated record ID for this repository.

change

Yields a change information value giving information about the last change to the repository record.

next

Yields the next source value in whatever list the current repository value happens to be a part of.

tagcode

Yields the string value "REPO", which is the GEDCOM tag name used for repository records.

tagname

Yields a translation of the word "Repository" into the currently selected output language.

Repository citation values:

Repository citation values correspond to source repository citation structures in the GEDCOM file.

repository

Yields a repository value indicating the repository associated with this citation.

notes

Yields a note value which is the head of a list of notes associated with this citation. Notes after the first can be accessed from the first by repeatedly applying the "next" qualifier.

caln

Yields an attribute value giving the call number associated with this citation.

serial

Yields an integer value ("serial number") that uniquely identifies the particular citation, and which can be used to create a hyperlink to it.

next

Yields the next repository citation in whatever list the current citation happens to be a part of.

tagcode

Yields the string value "REPO", which is the GEDCOM tag name used for repository citations.

tagname

Yields a translation of the word "Repository" into the currently selected output language.

Change information values:

Change information values correspond to change date structures in the GEDCOM file.

date

Yields a date value giving the date associated with this change information.

notes

Yields a note value which is the head of a list of notes associated with this change information. Notes after the first can be accessed from the first by repeatedly applying the "next" qualifier.

tagcode

Yields the string value "CHAN", which is the GEDCOM tag name used for change information.

tagname

Yields a translation of the word "Change" into the currently selected output language.

Header values:

A header value represents the information contained in the HEAD record that begins each GEDCOM transmission.

date

Yields a string value representing the date of the GEDCOM transmission.

filename

Yields a string value representing the name of the GEDCOM file, as recorded in the GEDCOM header record.

copr

Yields a string value representing the copyright notification that appears in the GEDCOM header record.

submitter

Yields a submitter value indicating the submitter that appears in the GEDCOM header record.

note

Yields a text value representing the note (if any) that appears in the GEDCOM header record.

tagcode

Yields the string value "HEAD", which is the GEDCOM tag name used for the GEDCOM header record.

tagname

Yields a translation of the word "Header" into the currently selected output language.

Multimedia values:

Multimedia values correspond to multimedia objects in the GEDCOM file. These value are not currently supported, and no qualifiers are currently defined for multimedia values.

Name values:

Name values represent names of individuals.

fullname

Yields a string value representing the full name, in a format suitable for printing.

gedcom

Yields a string value representing the full name, in GEDCOM format, with slashes delimiting the surname.

surname

Yields a string value representing the surname portion of the name.

sources

Yields a source citation value which is the head of a list of source citations for the name. Citations after the first can be accessed from the first by repeatedly applying the "next" qualifier.

notes

Yields a note value which is the head of a list of notes associated with this name. Notes after the first can be accessed from the first by repeatedly applying the "next" qualifier.

tagcode

Yields the string value "NAME", which is the GEDCOM tag name used for the GEDCOM header record.

tagname

Yields a translation of the word "Name" into the currently selected output language.

Attribute values:

Attribute values represent unstructured textual information associated with various GEDCOM substructures.

text

Yields a string value corresponding to the textual information contained in the attribute.

event

Yields an event value corresponding to the GEDCOM "event detail" (if any) associated with the attribute.

next

Yields an attribute value corresponding to the next attribute in whatever list the current attribute is a part of.

tagcode

Yields a string value giving the GEDCOM tag, such as "RESI", associated with this attribute.

tagname

Yields a string value that is a human-readable version of the GEDCOM tag indicating the particular type of attribute, rendered in the current output language. For example, for a RESI attribute, the tag would be "Residence" in English and "Domicile" in French.

Event values:

Event values correspond to event structures in the GEDCOM file.

text

Yields a text value that describes the event.

type

Yields a string value representing the contents of the TYPE field in the GEDCOM event record.

date

Yields a date value representing the date on which the event occurred.

place

Yields a place value representing the place at which the event occurred.

age

Yields a string value representing the contents of the AGE field in the GEDCOM event record.

agency

Yields an attribute value representing the contents of the AGNC field in the GEDCOM event record.

cause

Yields a string value representing the contents of the CAUS field in the GEDCOM event record.

sources

Yields a source value which is the head of a list of sources associated with this event. Sources after the first can be accessed from the first by repeatedly applying the "next" qualifier.

notes

Yields a note value which is the head of a list of notes associated with this event. Notes after the first can be accessed from the first by repeatedly applying the "next" qualifier.

family

Yields a family value representing the family associated with certain kinds of GEDCOM event records.

adoption

Yields a string value representing the contents of the ADOP field in the GEDCOM event record.

next

Yields the next event value in whatever list the current event value happens to be a part of.

tagcode

Yields a string value giving the GEDCOM tag, such as "BIRT", associated with this event.

tagname

Yields a string value that is a human-readable version of the GEDCOM tag indicating the particular type of event, rendered in the current output language. For example, for a BIRT event, the tag would be "Birth" in English and "Naissance" in French.

Place values:

Place values correspond to place structures in the GEDCOM file.

name

Yields a string value representing the name of the place.

tagcode

Yields the string value "PLAC", which is the GEDCOM tag name used for the GEDCOM place structure.

tagname

Yields a translation of the word "Place" into the currently selected output language.

REFN values:

REFN values represent user-defined reference numbers associated with various GEDCOM structures.

number

Yields a string value representing the reference number.

type

Yields a string value representing the reference type.

next

Yields a REFN value representing the next value in whatever list the current REFN value happens to be a part of.

tagcode

Yields the string value "REFN", which is the GEDCOM tag name used for the user reference number structure.

tagname

Yields a translation of the word "Reference" into the currently selected output language.

Text values:

Text values represent substructures consisting lines of textual data, such as are found in NOTE and SOURCE records. Text values often occur in linked lists representing an initial line and its continuations.

cont

Yields a text value representing a continuation of the current text, with an implied line break.

conc

Yields a text value representing a continuation of the current text, without any line break.

text

Yields a string value representing the line of textual data.

next

Yields the next text value in whatever list the current text value happens to be a part of.

tagcode

Yields a string value giving the GEDCOM tag, such as "AUTH", associated with this particular textual information.

tagname

Yields a string value that is a human-readable version of the GEDCOM tag indicating the particular type of textual information, rendered in the current output language. For example, for a AUTH event, the tag would be "Author" in English and "Auteur" in French.

Persons index values:

Index values do not correspond to anything in the GEDCOM standard. Rather, they are a notion introduced by GED2HTML to support the output of hierarchical indexes consisting of many interconnected "nodes", each of which covers a range of individuals. Each index value represents one node.

first

Yields an individual value corresponding to the first entry in the range covered by the current node.

last

Yields an individual value corresponding to the last entry in the range covered by the current node.

parent

Yields an index value corresponding to the index node "one level higher up" in the index.

children

Yields an index value which is the first in a list of index nodes "one level lower down" in the index. Subsequent index nodes can be accessed from the first by repeatedly applying the "next" qualifier.

succ

Yields an index value corresponding to the next node "at the same level" as the current node.

pred

Yields an index value corresponding to the previous node "at the same level" as the current node.

url

Yields a string representing a URL (uniform resource locator) which, when output as part of an HTML anchor, will create a hyperlink to the index node in question.

prev

Yields an index value corresponding to the previous node "with the same parent" as the current node.

next

Yields an index value corresponding to the next node "with the same parent" as the current node.

Surnames index values:

Surnames index values do not correspond to anything in the GEDCOM standard. Rather, they are a notion introduced by GED2HTML to support the output of hierarchical indexes of consisting of many interconnected "nodes", each of which covers a range of surnames. Each index value represents one node.

first

Yields an individual value corresponding to the first entry in the range of surnames covered by the current node.

last

Yields an individual value corresponding to the last entry in the range of surnames covered by the current node.

parent

Yields a surnames index value corresponding to the index node "one level higher up" in the index.

children

Yields a surnames index value which is the first in a list of index nodes "one level lower down" in the index. Subsequent index nodes can be accessed from the first by repeatedly applying the "next" qualifier.

succ

Yields a surnames index value corresponding to the next node "at the same level" as the current node.

pred

Yields a surnames index value corresponding to the previous node "at the same level" as the current node.

index

Yields a persons index value which is the "leaf" node of the persons index that contains the first person having with the first surname covered by the current node.

url

Yields a string representing a URL (uniform resource locator) which, when output as part of an HTML anchor, will create a hyperlink to the index node in question.

prev

Yields a surnames index value corresponding to the previous node "with the same parent" as the current node.

next

Yields a surnames index value corresponding to the next node "with the same parent" as the current node.

Ordinance values:

Ordinance values represent LDS ordinance information associated with an individual or family.

date

Yields a date value representing the date associated with the ordinance.

place

Yields a place value representing the place associated with the ordinance.

sources

Yields a source citation value which is the head of a list of citations associated with this ordinance. Citations after the first can be accessed from the first by repeatedly applying the "next" qualifier.

family

Yields the family value associated with a FAMC field in an SLGC ordinance.

status

Yields a string value giving the date status code associated with the ordinance.

temple

Yields a string value giving the temple code associated with the ordinance.

next

Yields an ordinance value representing the next value in whatever list the current ordinance value happens to be a part of.

tagcode

Yields a string value giving the GEDCOM tag, such as "SLGC", associated with this ordinance.

tagname

Yields a string value that is a human-readable version of the GEDCOM tag indicating the particular type of attribute, rendered in the current output language. For LDS ordinances, there are just two tags, SLGC, which would be rendered as "Sealing to parents" in English, and SLGS, which would be rendered as "Sealing to spouse" in English.

Address values:

Address values represent information found in a GEDCOM ADDR structure. Currently only the "address line" information in such a structure is accessible.

text

Yields a text value giving the address line text.

tagcode

Yields the string value "ADDR", which is the GEDCOM tag name used for the user reference number structure.

tagname

Yields a translation of the word "Address" into the currently selected output language.

Date values:

Date values correspond to date structures in the GEDCOM file.

value

Yields a string value representing the given date in the currently selected output language.

string

Yields a string value that gives the uninterpreted date exactly as it appeared in the GEDCOM file.

exact

Yields an integer value that is nonzero if the given date is an exact date, rather than an approximate date or date range.

day

Yields an integer value identifying the day of the month selected from the given date.

month

Yields an integer value identifying the month selected from the given date.

year

Yields an integer value identifying the year selected from the given date.

tagcode

Yields the string value "ADDR", which is the GEDCOM tag name used for the user reference number structure.

tagname

Yields a translation of the word "Address" into the currently selected output language.

List of all Special Variables

Note that variables are sensitive to upper/lower-case distinctions.

Read-only Variables

PATH_TO_ROOT

Yields a string value which gives the path from the output file currently being generated to the "root" of the output tree being constructed by GED2HTML. This variable can be used to construct relative URL's in the current output file that will work for any combination of output processing options.

PERSONS_URL

This variable has a string value, which is a relative URL suitable for reaching the top-level index of persons. The value of this variable is affected by the "CASE_FOLD_LINKS" option and the "FILENAME_TEMPLATE" option.

SURNAMES_URL

This variable has a string value, which is a relative URL suitable for reaching the top-level index of surnames. The value of this variable is affected by the "CASE_FOLD_LINKS" option and the "FILENAME_TEMPLATE" option.

NUMBER_OF_FAMILIES

Yields an integer value representing the number of family records contained in the GEDCOM being processed.

NUMBER_OF_SOURCES

Yields an integer value representing the number of (level 0) source records contained in the GEDCOM being processed.

NUMBER_OF_NOTES

Yields an integer value representing the number of (level 0) note records contained in the GEDCOM being processed.

HEADER

Yields a header value representing the information gleaned from the HEAD record of the GEDCOM being processed.

VERSION

Yields a string value which describes the version of GED2HTML that is executing.

OSTYPE

Yields a string value which describes the operating system that the executing version GED2HTML was compiled for.

TODAY

Yields a string value representing the date of the run.

Read/Write Variables

FILES_PER_DIRECTORY

A number assigned to this variable determines the number of individual data files GED2HTML will put in a single subdirectory. The default value is 100. If 0 is assigned to this variable, then GED2HTML will not use any subdirectories. Instead, it will create a "flat" structure in which all output files reside in the same directory.

INDIVIDUALS_PER_FILE

Setting this variable to an integer value determines the number of individuals GED2HTML will try to put in each of the individual data files it creates. Putting several individuals in a single file tends to save disk space on many systems. The default value is 10. To force GED2HTML to put exactly one individual per file, assign 0 to this variable.

NOTE: If "STABLE_FILENAMES" has a nonzero value (the default), then GED2HTML treats a positive value assigned to "INDIVIDUALS_PER_FILE" as a target value. It does not necessarily guarantee to put exactly the specified number of individuals in each file. If you must have exactly the specified number of individuals in each file, then initialize "STABLE_FILENAMES" to zero.

NOTES_PER_FILE

For GEDCOMs containing many notes records, putting all the notes in a single HTML file can produce a file that is too large to be downloaded conveniently over the Web. Assigning a nonzero value to this variable causes GED2HTML to output notes to multiple files, with the total number of notes output in any one file limited to the specified value. The default value is 0, which means put all notes in a single notes file.

SOURCES_PER_FILE

For GEDCOMs containing many source records, putting all the sources in a single HTML file can produce a file that is too large to be downloaded conveniently over the Web. Assigning a nonzero value to this variable causes GED2HTML to output sources to multiple files, with the total number of sources output in any one file limited to the specified value. The default value is 0, which means put all sources in a single sources file.

NUMBER_OF_DIRECTORIES

A nonzero number assigned to this variable forces GED2HTML to use a fixed number of subdirectories to contain the individual data files. The default value is 0, which permits GED2HTML to use as many directories as it sees fit. Note that a nonzero value assigned to this variable causes any value entered in "INDIVIDUALS_PER_FILE" to be ignored, and GED2HTML will put as many individuals as necessary in each file in order to output all the individuals using the specified number of directories and files per directory.

UPPER_CASE_SURNAMES

Assigning a nonzero value to this variable causes all surnames to be converted into upper case as the GEDCOM is read. The default value is 1. For international characters, conversion into upper case depends on the current setting of the "LOCALE" variable.

STABLE_FILENAMES

Assigning a nonzero value to this variable enables a feature that causes GED2HTML to use a "hash function" to calculate the directory and file in which the data for a given individual will appear, directly from the GEDCOM identifier (RIN) for that individual. This has the advantage of making the mapping from individuals to directory/file pairs "stable" under additions to and deletions from the GEDCOM. This means that if you process your GEDCOM once, then add some new individuals to it and process your GEDCOM again, the second time all the individuals that were there the previous time end up in the exact same place in the output file as they did the first time. This feature can be advantageous for linking from external documents into the HTML tree output by GED2HTML. See here for more details. The default value is 1.

The disadvantages of using "STABLE_FILENAMES" are: (1) GED2HTML has less control over exactly how many individuals will end up in any given file; (2) the hash function randomizes the individuals so that a particular file will generally contain a number of completely unrelated individuals, rather than a group of individuals with the same surname.

LANGUAGE

The string assigned to this variable selects the (human) language that will be used to render the names of various GEDCOM tags in the HTML output. For example, if "English" is assigned to LANGUAGE then the GEDCOM tag "BIRT" will be rendered in the output as "Birth". If, instead "French" is assigned to LANGUAGE, then the GEDCOM tag "BIRT" will be rendered as "Naissance". The currently available choices are "English", "French", "Danish", "Dutch", "German", "Italian", "Norwegian", "Swedish", and "Finnish".

Setting the "LANGUAGE" variable actually has three distinct effects:

1. Various GEDCOM tags in the input file are rendered in the HTML output according to the chosen language. For example, if "English" is chosen, then the GEDCOM tag "BIRT" will be rendered as "Birth". On the other hand, if "French" is chosen, then this tag will be rendered as "Naissance". The specific translations of the GEDCOM tags are compiled into GED2HTML and are currently not directly customizable by the user. This may change in a future version of GED2HTML.

2. The chosen language influences the choice of certain text strings and punctuation in the HTML output. The complete list of these strings can be found in the GED2HTML output program, and can be customized by modifying this program, as described here.

3. When you enter a language name in the "Language" field, GED2HTML also initializes the "LOCALE" variable to correspond to the chosen language. The locale affects the translation and formatting of dates that appear in the GED2HTML output, as well as the collating sequence and upper/lower case conversions for international characters. The correspondence between languages and locales is precompiled into GED2HTML. However, if you find that the preselected locale to be inappropriate, you can set the locale independently by setting the LOCALE output interpreter variable to the desired locale name. NOTE: Locales are not supported by GED2HTML running under Windows 3.1. See here for more details on variables and the output interpreter.

   For a list of all the output interpreter variables that can be initialized to select processing options, see here.

CHARACTER_SET

The string value assigned to this variable controls the way in which GED2HTML interprets characters in the GEDCOM file. The possible values are: "ASCII", "ANSI", "ANSEL", "IBM WINDOWS", "MS-DOS", and "IBMPC". If no explicit assignment is made to this variable, then it gets initialized from the CHAR field of the GEDCOM header when the GEDCOM is read. If this variable receives an explicit assignment, then the value in the GEDCOM header is ignored. The default is ANSI (ISO-Latin-1), in case the character set cannot otherwise be determined.

PEDIGREE_DEPTH

The value assigned to this variable controls the number of generations of ancestors that appear in the pedigree charts output in each individual data page. The default value is 2. Assigning a value of 0 turns off the production of pedigree charts.

FILENAME_TEMPLATE

A string value assigned to this variable is interpreted as a pattern to be used in constructing the names of the various HTML output files. The default is "%s.html", which indicates the name of an HTML output file is constructed by taking a base string and concatenating it with ".html".

ERROR_FILE

A string value assigned to this variable is interpreted as the name of a file to be used to log any errors that occur during the processing of the GEDCOM. The default value is "g2herrs.txt".

DESTINATION_DIRECTORY

A string value assigned to this variable is interpreted as the name of a directory in which the HTML files output by GED2HTML should be put.

OUTPUT_PROGRAM

A string value assigned to this variable is interpreted as the name of an alternate output program file, to be used to control the production of the HTML output files. See here for more information on output programs.

CASE_FOLD_LINKS

This variable controls certain processing to be performed on the URLs output in HTML anchors (hyper-links). If the value "Lower" is is assigned to this variable, then all URLs output by GED2HTML as part of HTML anchors are converted (folded) to lower case before being output. If the value "Upper" is assigned to this variable, then all URLs are converted to upper case. If the value "None" is assigned, then no conversion of any kind is performed. The default is "None".

The reason for this feature is to accomodate the ideosyncrasies of various systems and uploading software having to do what happens to MS-DOS-style upper-case-only filenames when the files are uploaded from a Windows system to a Web service provider's system. Generally speaking, "None" is the correct initialization for this variable on a Unix system.

GENERATE_INDEX

Assigning a nonzero value to this variable enables the creation of the persons and surnames indexes. The default value is 1.

GENERATE_INDIVIDUALS

Assigning a nonzero value to this variable enables the creation of the data pages for individuals. The default value is 1.

GENERATE_SOURCES

Assigning a nonzero value to this variable enables the creation of the sources files. The default value is 1.

GENERATE_NOTES

Assigning a nonzero value to this variable enables the creation of the notes files. The default value is 1.

GENERATE_GENDEX

Assigning a nonzero value to this variable enables the creation "GENDEX.txt" index file, which can be used by the GENDEX genealogical index to centrally index your data so that others can find it more easily. The default value is 1.

INDEX_WIDTH

The value assigned to this variable controls the maximum number of entries in each page of the hierarchical persons index. The default value is 28, which means that each index page will contain links either up to 28 individual data pages, or up to 28 "lower-level" index pages. In general, the more entries per page, the fewer "levels" of index are necessary to index a given number of individuals. Assigning 0 to this variable turns off the hierarchical index feature, causing a "flat" index to be created in which all individuals appear in a single index page.

Note that GED2HTML does not always put the maximum number of individuals in an index page. Rather, it tries to adjust the number of individuals in an index page to avoid producing lots of "widow" pages that contain very few entries. It generally succeeds at this, except that it is sometimes the case that the top-level index page has as few as two entries in it. This situation can generally be avoided by increasing the index width a bit.

SURNAME_WIDTH

For large GEDCOMs, putting all the surnames in a single surnames file can produce a file that is too large to download conveniently over the Web. Assigning a nonzero value to this variable causes GED2HTML to create a multiple-file surname index, in which the number of surnames in any given file is limited to the specified value. The default value is 0, which causes GED2HTML to put all the surnames in a single file.

DOS_CODE_PAGE

Assigning an integer value to this variable selects the DOS code page to be used for GEDCOM's encoded using IBMPC or MS-DOS character sets, as determined by the CHAR field in the GEDCOM header. Currently supported code pages are 437 (United States), 863 (Canadian-French), and 850 (Multilingual/Latin I). If an unrecognized value is assigned to this variable, the code page defaults to 850.

LIVING_CUTOFF_YEAR

This variable has an integer value. If nonzero, then GED2HTML presumes that all individuals born or christened during this year or a later year are living unless they also have an explicitly recorded death or burial date, or unless the variable LIVING_IGNORE_DEATH has a nonzero value. The default value is zero, which disables this feature. See here for more information on eliding information about living individuals.

LIVING_IGNORE_DEATH

This variable has an integer value. If nonzero, then GED2HTML does not automatically assume that a person is dead just because there is death or burial information. The default value is zero, which disables this feature. Setting this variable to a nonzero value, in combination with an appropriate setting of LIVING_CUTOFF_YEAR, can be used to suppress information about individuals born or christened since a particular date. See here for more information on eliding information about living individuals.

LIVING_NOTE

This variable has a string value, which is inserted as an explanatory note on data pages for individuals that have automatically been presumed to be living. Assigning to this variable changes the default text of the note. See here for more information on eliding information about living individuals.

LOCALE

The string value of this variable controls the formatting of dates, as well as the collating sequence and details of upper/lower conversion for international characters. Normally this variable does not need to be set explicitly, as it is set automatically as a result of selecting a particular output language. However, one can set this variable to override the default choice associated with the selected output language. The possible values are system dependent, and require that you have knowledge of the locales supported by your operating system. For additional related discussion, see here. NOTE: Locales are not supported by GED2HTML running under Windows 3.1.

USE_LOCAL_TIME

If this integer variable has a nonzero value, then time-of-day information appearing in the output will be with respect to the local time zone, rather than GMT (UTC). The default value is zero.

Other Variables

CONT_MEANS_BREAK

If this variable has a nonzero value, then notes records in the GEDCOM that are continued over several GEDCOM lines using the CONT tag will be rendered in the HTML output with a line break <BR> before each CONT line. Continuation lines that use the CONC tag are rendered without a line break. This seems to correspond to the spirit of what the GEDCOM standard has to say about the use of CONT and CONC, however the output of some genealogy programs looks ugly this way. In such cases, assigning a value of zero to this variable CONT be rendered exactly like CONC; that is, without a line break. The default value is 1.

MAILTO

A string value assigned to this variable is interpreted as an E-mail address, and an HTML "mailto:" link to this address is inserted into the "top-level" persons and surnames index pages. The purpose is to make it easy for people to contact you, no matter where in your data they are looking.

HOMEPAGE

A string value assigned to this variable is interpreted as an URL, and a hyperlink to this URL is inserted into each of the output pages. The purpose is to make it easy for people to get back to your home page, no matter where in your data they are looking.

BACKGROUND_COLOR

This variable has a string value, which is inserted on each page of output as the "BGCOLOR" attribute of the HTML "<BODY>" tag. For example, setting this variable to "#ffffff" will set a white background.

BACKGROUND_IMAGE

This variable has a string value, which is inserted on each page of output as the "BACKGROUND" attribute of the HTML "<BODY>" tag. For example, setting this variable to "foo.gif" will cause the image file "foo.gif" to be used as the background image.

TEXT_COLOR

This variable has a string value, which is inserted on each page of output as the "TEXT" attribute of the HTML "<BODY>" tag. For example, setting this variable to "#ff0000" will make red the default text color.

LINK_COLOR

This variable has a string value, which is inserted on each page of output as the "LINK" attribute of the HTML "<BODY>" tag. For example, setting this variable to "#00ff00" will cause hyperlinks to be rendered in green.

VISITED_COLOR

This variable has a string value, which is inserted on each page of output as the "VLINK" attribute of the HTML "<BODY>" tag. For example, setting this variable to "#0000ff" will caused visited hyperlinks to be rendered in blue.

INLINE_NOTES

The integer value of this variable controls whether notes occuring at level 0 in the GEDCOM file will be placed on the same page as the individual or family that references them, or whether they will instead be placed in a separate notes files. The default value is zero, which means that the notes will be placed in a separate notes file.

INLINE_SOURCES

The integer value of this variable controls whether sources occuring at level 0 in the GEDCOM file will be placed on the same page as the individual or family that references them, or whether they will instead be placed in a separate sources files. The default value is zero, which means that the sources will be placed in a separate sources file.

OMIT_META

The integer value of this variable controls whether or not HTML "META" tags will be inserted into the output pages. META tags supply various kinds of keywords and descriptive information that can help a browser display the document, and also can help Web indexing and search engines classify the document more appropriately. The default value is 0, which means that META tags will be output.

FAMILY_GROUPS

The integer value of this variable determines whether the output will be in the "traditional" GED2HTML individual-based format, or in a newer "family group sheet" format. The default is zero, which means the traditional format is used.

NO_ALPHABET_TABS

The integer value of this variable controls whether or not an "alphabet tab" style surnames index will be produced. The default value is zero, which means that by default, the alphabet tab style will be used for the surnames index, as long as the special variable SURNAME_WIDTH is zero. If NO_ALPHABET_TABS is nonzero, or SURNAME_WIDTH is nonzero, then the "traditional" GED2HTML format will be used instead.

GED2HTML home page

GED2HTML: Commonly Encountered Problems

Typical Windows Problems

• I can't figure out how to run the program under Windows. When I try to run G2H.EXE, a window pops up with a message I can't understand and it just sits there.

• Everything looks fine on my PC, but when I upload the files to my Web service provider, all the HTML files have suffix ``.htm'' and Netscape doesn't seem to interpret them as HTML files.

• Under Windows 3.1, how can I create all the output files so that their names end in ``.html'', rather than ``.htm''.

• I am running Windows 3.1. How can I cause all the HTML files to be generated so that the links in all the individual files specify filenames ending in ``.html'', rather than ``.htm''?

• My Web provider needs to have filenames in 8.3 format, but when running GED2HTML under Windows 95, all the files and links are created with extension ".HTML" instead of ".HTM". When I upload to my provider, none of the links work anymore. How can I arrange for the links to say ".HTM" instead of ".HTML"?

• After I upload all the HTML files to my Web service provider, none of the links work, because the file names are all in upper case, but the links specify the file names in lower case.

• I paid my registration fee, now how can I make the program stop putting the UNREGISTERED message in each of the output pages?

• GED2HTML doesn't seem to find my "include files", which contain HTML code to pull in images of each person in my database. What's wrong?

• I wanted to change the background color on my HTML pages, and I tried to put

  print "<BODY BGCOLOR="#66ccff">" ;

  in the output template. But GED2HTML didn't accept even this simple change.

• How can I use the GIF file "foo.gif" as a background image?

Typical Unix Problems

• When I try to compile the program under Unix, I get millions of syntax errors. What is wrong?

• When I link the program under Unix, I get a message ``Undefined symbol _fgetln''. What is wrong?

• When I link the program under Unix, I get a message ``Undefined symbol _strdup''. What is wrong?

• When compiling tags.c under Unix, the compiler complains about incompatible types at the line containing ``bsearch()''. What should I do?

• When compiling main.c under Unix, the compiler complains about SEEK_END being undefined. What should I do?

• When compiling output.c under Unix, the compiler complains about FILENAME_MAX being undefined. What should I do?

• When compiling using gcc under SunOS 4.1.3, I get lots and lots of compiler warnings, but the program compiles and runs. Is this OK?

Answers to Problems

A: Don't run G2H.EXE directly. The proper way to launch GED2HTML is to run GED2HTML.EXE, which will pop up a dialog box. The program G2H.EXE gets called automatically from GED2HTML.EXE, once the GEDCOM file and program options have been selected and processing starts.

A: This is a somewhat technical problem. The easiest solution requires the cooperation of your Web service provider. Web servers generally have a ``mime.types'' configuration file, which lists mappings from filename suffixes to MIME types. This information allows the server to determine what kind of information is in a file by looking at the suffix. The server communicates this information to your browser when the file is retrieved, and the browser, in turn, uses the information to control how the file is displayed. Some servers lack an entry:

A: You can't. The reason is that DOS only supports three-letter filename suffixes, and will truncate anything longer than that. The Windows 95 version of the program does not have this limitation.

A: You can do this by putting

-D FILENAME_TEMPLATE="%s.html"

A: Put the following in the "Additional Options" field of the GED2HTML dialog box:

-D FILENAME_TEMPLATE="%s.HTM"

A: Under Windows, reprocess your GEDCOM with the "Upper" radio button selected in the "Case fold links" button group. Under Unix, initialize the output interpreter variable CASE_FOLD_LINKS to "Upper".

A similar procedure applies if the file names are all in lower case, but the links specify the file names in upper case. See here for a more detailed discussion of the upper-case/lower-case issue.

A: GED2HTML looks for the include files in the destination directory, which is typically called "HTML", and which is where the output files and directories get produced. This is admittedly somewhat counterintuitive, and it might be changed in the future. In the meantime, note that there is a mechanism by which you can use a modified output program to change the directory in which GED2HTML looks for the include files. Specifically, you can change the line that reads:

include i.xref ^ ".img"

include INCLUDE_DIR ^ i.xref ^ ".img"

-D INCLUDE_DIR="C:\MYDIR\"

For more information on modifying the GED2HTML output program, see here.

print "<BODY BGCOLOR="#66ccff">" ;

A: First of all, you probably don't want to be doing this, because the standard GED2HTML output program already has an option for setting the background color. Simply put:

-D BACKGROUND_COLOR="#66ccff"

If you really do think you want to edit the output program, note that in the output language, it is necessary to escape double quotes within string constants by using a preceding backslash. Thus, the correct change would be:

print "<BODY BGCOLOR=\"#66ccff\">" ;

A: Put

-D BACKGROUND_IMAGE="foo.gif"

A: When I receive your registration, I will send you a password which you can use to download the full version of the program from here. The full version of the program does not produce the UNREGISTERED message.

Q: When I try to compile the program under Unix, I get millions of syntax errors. What is wrong?

A: You are trying to compile the program with a pre-ANSI C compiler. It cannot understand ANSI function prototypes. Get an ANSI C compiler, such as gcc, and use that.

A: You are running on an older or non-BSD version of Unix that does not have the ``fgetln()'' function. I actually wrote my own implementation of fgetln() and put it in the code, but it is #ifdef'ed out because I would rather use a library version if it exists. Edit the Makefile and delete the ``-DHAVE_FGETLN'' from the ``CFLAGS'' line. Then re-run ``make''.

A: You are running on a version of Unix that does not have the ``strdup()'' function. There is code for it, but it is #ifdef'ed out because I would rather use a library version if it exists. Edit the Makefile and delete the ``-DHAVE_STRDUP'' from the ``CFLAGS'' line. Then re-run ``make''.

A: It may be necessary to place the cast (struct tag *) in front of the call to bsearch() in tags.c, or possibly to change the cast on the function argument to bsearch to make the compiler happy. This is not necessary with gcc, and it is my belief that it should not be necessary under ANSI C.

A: Some people have found that they need to #include <unistd.h> in main.c. My belief is that ANSI C dictates that the constant SEEK_END should be in <stdlib.h>. If you are having this problem, try #include'ing <unistd.h> too.

A: Add -DFILENAME_MAX=1024 to the CFLAGS line in the Makefile, and recompile.

A: Yes. SunOS 4.1.3 does not have fully ANSI prototyped header files, and you are compiling the program using the -Wall option, which causes gcc to produce warnings for the slightest thing. If you remove -Wall from the CFLAGS line in the Makefile, the program will compile quietly.

GED2HTML: Miscellaneous Other Topics

• Family-group-sheet style output.
• International characters and GED2HTML.
• Linking from other HTML documents into the GED2HTML output files.
• Inserting images into the HTML output pages.
• Eliding information about living individuals from the HTML output.
• Library of output program code contributed by GED2HTML users.

GED2HTML home page

GED2HTML: Family Group Style Output

Family group style output, is enabled by setting the output interpreter variable FAMILY_GROUPS to a nonzero value. Under Windows 95 and Windows 3.1 this is done by checking the "Family Group Sheet" radio button under "Output Style" on the "More Options" dialog screen. Alternatively, put -D FAMILY_GROUPS=1 either in the "Additional Options" field of the dialog box under Windows 3.1 and Windows 95, or else on the command line under Unix. When family group style output is enabled, the number of family group sheets that are put in a single output file is controlled by the INDIVIDUALS_PER_FILE variable. See here for further information on customizing GED2HTML output.

GED2HTML home page

International Characters and GED2HTML

Internally, GED2HTML "supports" the ISO-Latin-1 character set. What this really means is that, aside from possibly converting ASCII characters with codes 127 or less from lower case to upper case, the processing performed by GED2HTML simply treats characters in the GEDCOM as 8-bit values to be passed through from input to output. According to my reading of the HTML specification, a compliant ``user agent'' (e.g. a browser) should accept HTML files encoded using this character set. Netscape, for example, will read and display such characters properly. If a browser ``barfs'' on characters with codes 128 and above, then it is not an HTML-compliant browser.

A number of people have complained that GED2HTML versions prior to version 3.0 "didn't support international characters". What this generally meant was that their GEDCOMs were encoded in some IBM-PC character set, and when the 8-bit codes from their GEDCOMs were passed through to the HTML output and interpreted by an HTML-compliant browser, the characters that were displayed by the browser did not appear the same as the ones they originally entered using their genealogy program.

To help with this problem, GED2HTML version 3.0 and later now applies the following procedure which is intended to make more GEDCOMs produce output that matches the user's expectations:

1. When a GEDCOM is read, GED2HTML uses the information in the CHAR field of the HEAD record to attempt to determine the character set in which the GEDCOM is encoded. Currently, GED2HTML recognizes the tokens "ASCII", "ANSI", "ANSEL", "IBM WINDOWS", "MS-DOS", and "IBMPC". The default is ANSI (ISO-Latin-1), in case the character set cannot otherwise be determined.

2. As the GEDCOM is read in, GED2HTML attempts to translate it, from the character set in which it is encoded, to the "equivalent" encoding in ISO-Latin-1. It is not always possible to do an exact job of this, because, for example, there are ANSEL sequences for which there is no ISO-Latin-1 equivalent. Anyway, it does the best it can, and I am open to suggestions for improvement.

3. Once the data has been translated internally into ISO-Latin-1, no further change (other than possible lower/upper case conversions to characters with codes less than 128) is made to the data, before it is eventually emitted as HTML output.

1 CHAR IBMPC

1 CHAR ANSI

Locales

Some people seem to feel compelled to put HTML "entity codes" (e.g. &ouml) in their GEDCOM's. My opinion on this is that these codes are HTML-specific, and have no business being in a GEDCOM. If I were trying to be really nice to non-compliant HTML browsers, I would translate ISO-Latin-1 characters in the range (128-255) to their HTML "entity codes" when creating the HTML files. I might still implement this, but it is not a high priority, because in my opinion (supported by the HTML spec cited above) a browser that cannot display these codes is broken.

GED2HTML home page

Linking from Other Documents into the GED2HTML Output Files

When you run GED2HTML, it outputs a directory structure consisting of a number of subdirectories (D0001/, D0002/, D0003/, etc.) and files within subdirectories (either G0000001.html, G00000002.html, G0000003.html, etc., or else I1.html, I2.html, I3.html, etc., depending on whether you have asked for multiple individuals to be placed in a single output file). For the purposes of discussion, let's suppose that the Dxxxx/ directories are all located under a single top-level directory HTML/ (this is the default under Windows).

Now, suppose you wish to include the output of GED2HTML in a hypertext book you are writing. You might create a top-level directory BOOK/, and with the HTML/ directory a subdirectory. The text of your book might be in files chap1.html, chap2.html, chap3.html, etc. under a TEXT/ subdirectory of the BOOK/ directory. So, you would have the following directory and file structure:

Suppose you want to put a link in the HTML file "chap1.html" that links to individual "Joe Blow" with RIN "I151", whose HTML file output by GED2HTML happens to be in file

The relative URL as above has the advantage that you can move the whole BOOK/ directory tree somewhere else on the system, and you won't have to change any of the links. However, if you change the position of the file "chap1.html" relative to the HTML/ directory, you will have to change the URL to reflect the difference.

Now, let's consider what happens if you add more data to your GEDCOM, and you'd like to reprocess it for your book. Ideally, you would just re-run GED2HTML and replace the contents of the HTML/ directory by the output files from the new run. This works, as long as you don't change the number of individuals in your GEDCOM. If you change the number of individuals between runs, then on the second run, GED2HTML might decide to use a different number of directories than it did on the first run. This is because the default behavior of GED2HTML is to figure out how many directories you need to hold all your data, with the default number of files per directory and individuals per file. If GED2HTML decides more directories are needed on the second run, then after this run all the links in your book will point to the wrong places.

Fortunately, there is a way around this difficulty. GED2HTML includes a "stable filenames" option in which the subdirectory and file a particular individual should go in is calculated from the individuals cross-reference ID using something technically known as a "hash function". If "stable filenames" are enabled, then as long as the same number of subdirectories and files per subdirectory are being used, the same individuals will end up in the same places, regardless of what other individuals have been added to or deleted from the GEDCOM.

By default, GED2HTML has a certain number of individuals that it tries to put in each file. It computes the required number of subdirectories and files per subdirectory based on this parameter and the total number of individuals in the GEDCOM. However, if you change the number of individuals in your GEDCOM and you wish to take advantage of the stable filenames option, then you need to tell GED2HTML to use a specific number of directories and a specific number of files per directory. GED2HTML permits you do to this by specifying the appropriate processing options.

So, suppose the first time you run GED2HTML you use the default options, which under Windows are 10 individuals per file, 100 files per subdirectory, and as many subdirectories as are needed. Suppose you ended up with three subdirectories: D0001/, D0002/, and D0003/. You then add links from the text of your book into the HTML pages in these subdirectories. At a later date, after modifying your GEDCOM, you decide you want to re-run GED2HTML on the new GEDCOM. You should tell GED2HTML on this second run to use three subdirectories and 100 files per subdirectory. As a result, all individuals that were present in the original GEDCOM will end up in the same files after the second run as they did after the first.

There are two disadvantages to the "stable filenames" feature, which might make you want to disable it if you are not trying to link into your database from external documents. The first disadvantage is that the assignment of individuals to files using stable filenames appears random, so that individuals from the same family group will not likely end up in the same file. The second disadvantage is that using stable filenames GED2HTML is not always able to do a very good job at packing a uniform number of individuals in each file. If you disable the stable filenames feature, then GED2HTML assigns individuals to files in alphabetical order by surname, and it always puts the maximum number of individuals in each file.

GED2HTML home page

Including HTML Code Inline

The second place where the standard template allows for arbitrary inclusions is at the end of the information for each individual. At this point, GED2HTML looks for a file "xxxxx.inc". It is intended (though again not required), that this file would include any additional notes or information about this person not present in the original GEDCOM file. For example, I have used this in my hypertext family history document to link to things like wills and divorce records.

If you customize the output program, you can arrange for inlining anything you want, using the same mechanism as is used by the default program. For more information on customizing the output program, see here.

GED2HTML home page

GED2HTML: Eliding Information about Living Individuals

Manual Method

When GED2HTML sees a note of this form in the information about an individual, it sets a special "living" flag for that individual. The "living" flag can be accessed in the output program by applying the qualifier "living" to the individual. When the standard output program encounters an individual for which the "living" flag is set, it outputs only the name of the individual and the note that begins with the !LIVING string. No other information about the individual is output. The name of the individual will appear in the index of persons, but it will not appear in the GENDEX.txt file.

Automatic Method

If you have set LIVING_CUTOFF_YEAR to a nonzero value, then each time GED2HTML reads an individual from your GEDCOM file, it performs the following steps:

1. If the individual has already been flagged as living, by the presence of a "!LIVING" note inserted manually, then nothing else special is done.

2. If the individual has either a birth or a christening date, and the individual does not have a death date or a burial date, and if the year of birth or christening is greater than or equal to the value of LIVING_CUTOFF_YEAR, then the individual is automatically flagged as living. The living flag can be accessed from the output interpreter by applying the qualifier "living" to the individual, just as in the manual method. The text of the explanatory note can be changed by assigning a string value to the variable LIVING_NOTE.

If LIVING_CUTOFF_YEAR has been set, and an individual was born or christened after the specified year, and in addition, there is explicit death or burial information for the individual, then the default behavior of GED2HTML is to assume the individual is dead and that information about that individual need not be suppressed. If this assumption is not appropriate (for example, in France it is against the law to distribute information about persons born too recently, whether or not they are already dead), then setting the variable LIVING_IGNORE_DEATH to 1 will cause GED2HTML not to assume that an individual is dead simply because there is death or burial information for that individual.

GED2HTML home page

GED2HTML: Library of Output Program Code Contributed by GED2HTML Users

GED2HTML home page