no edit summary
=== Generating XML ===
The easiest way to generate an XML file is to export the data. This can be done from the File->Export menu. This will generate a file with a <
tt>.gramps</ tt> extension. This file is usually a gzip'd XML file (depending on some system settings, sometimes this will be an uncompressed XML file).
GRAMPS compresses the file because XML files can become rather large. For large databases, this file could grow to 10s to 100s of megabytes in size. Fortunately, XML files compress nicely, usually producing a fairly small size.
=== How do I tell if the XML file is compressed? ===
The easiest way is to run the <
tt>file</ tt> command on it.
$ file data.gramps
$ gunzip < data.gramps > data.xml
This example creates an uncompressed <
tt>data.xml</ tt> file from the compressed < tt>data.gramps</ tt> file.
You must use the I/O redirection operators (">" and "<"), since <
tt>gzip</ tt> expects files to have a < tt>.gz</ tt> extension.
=== I am confused. How do I extract editable XML from .gramps file? ===
For these reasons, we must rely on the <code>.gramps</code> extension. If we don't, we would not be able to tell if this was a valid file. Even worse, the mime type of <code>application/x-gzip</code> would be associated with another application (such as File Roller or Ark) instead of GRAMPS. The mime type of <code>application/xml</code> may be associated with XML editors (Bluefish, Conglomerate, Emacs, etc). In that situation, the user double-clicking on the file in the file manager (or performing the default action for the type by any other means) will never launch GRAMPS with this data,
GRAMPS is not unique in this problem. For example, the OpenDocument format used by OpenOffice, KWord and AbiWord is actually a collection of files in a <
tt>zip</ tt> archive. If you run < tt>unzip</ tt> on a OpenDocument file, you will see something like:
$ unzip test.odt