print "<BODY BGCOLOR="#66ccff">" ;in the output template. But GED2HTML didn't accept even this simple change.
A: These errors are produced because Family Tree Maker does not produce GEDCOM files that are completely GEDCOM-5.5 compliant. There should not be any period after the keywords "BEF", "AFT", and "BET". You can ignore the error messages, though this could affect GED2HTML's ability to do automatic detection of living individuals, because it will not understand some of the dates in your GEDCOM. As a workaround, you can edit the GEDCOM and remove the periods before running GED2HTML.
A: These errors are produced because Family Tree Maker does not produce GEDCOM files that are completely GEDCOM-5.5 compliant. What should follow the ALIA tag is not a person's name, but rather a cross reference such as @I123@. This error is not very important, and probably doesn't even affect the output of GED2HTML. If you like, you can get rid of the error message by editing the GEDCOM and changing all occurrences of "ALIA" to "NOTE ALIA".
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 version of the program does not have this limitation.
A: You can do this by putting
-D FILENAME_TEMPLATE="%s.html"in the "Additional Options" field in the GED2HTML dialog box. See here for information on supplying additional options to the Windows version of GED2HTML, and here for information on the special output interpreter variables that can be used to customize GED2HTML behavior.
A: Put the following in the "Additional Options" field of the GED2HTML dialog box:
-D FILENAME_TEMPLATE="%s.HTM"For a further discussion of the HTM/HTML issue, see here. See here for information on supplying additional options to the Windows version of GED2HTML, and here for information on the special output interpreter variables that can be used to customize GED2HTML behavior.
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"to read instead:
include INCLUDE_DIR ^ i.xref ^ ".img"You will then need to put, for example:
-D INCLUDE_DIR="C:\MYDIR\"in the "Additional Options" field of the dialog box. The effect of these two changes will be that GED2HTML will look for your image files in the directory
C:\MYDIR\, instead of the destination directory.
For more information on modifying the GED2HTML output program, see here.
print "<BODY BGCOLOR="#66ccff">" ;in the output program. But GED2HTML didn't accept even this simple change.
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"in the "Additional Options" field under Windows, or as an additional command line argument under Unix. This is one of a number of customizations that are controlled by setting variables in the output interpreter. For a complete list of all such variables and the customizations they control, see here.
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\">" ;The escapes are necessary, because otherwise there would be no way to tell a quote that ends a string constant from a quote that is part of the string to be printed. The complete set of escapes understood within string constants is documented here.
-D BACKGROUND_IMAGE="foo.gif"in the "Additional Options" field under Windows, or as an additional command line argument under Unix. This is one of a number of customizations that are controlled by setting variables in the output interpreter. For a complete list of all such variables and the customizations they control, see here.
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''.
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.
-DFILENAME_MAX=1024 to the
CFLAGS line in
the Makefile, and recompile.
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
CFLAGS line in the Makefile, the program will
Copyright © 1995-2004 Eugene W. Stark. All rights reserved.