DevTools:Modules
basrol lizeldomac relnoero
Contents
Module Development
A SWORD module consists of a set of binary files in any of an increasing number of formats created for SWORD plus a .conf file that specifies the location and attributes of the module.
The .conf file is located in a standard location, such as the mods.d directory of the SWORD install directory, that may be specified to The SWORD Engine in a number of ways that are outside the scope of this document. This file can be created with a standard text editor like notepad, emacs, vi, or pico. Its contents are described below in section II.
The module files themselves usually require an amount of pre-processing before they are ready to be imported to SWORD. How you go about this pre-processing is something you will need to decide for yourself. You may be able to do all of your pre-processing with simple search & replace operations in notepad or more complex regular expression search & replace operations in emacs, but the majority of modules will probably require even more complex editing using a scripting language such as Perl plus a fair amount of manual correction. On the other hand, some modules may come in a standard format such as ThML or OSIS encoded files, which does not require any modification, assuming they are valid documents. Document pre-processing is outside the scope of this document, but we will explain how you need to format documents to prepare them for import to SWORD, both in terms of encoding and markup.
Once you have a document ready for import, you will need to run it through an importer to create the SWORD module files, which will then be placed in the module directory you specify in your .conf file.
After this, you may test your work and consider submitting it to The SWORD Project for public distribution from our website.
Creating a .conf File
.conf File Layout
The conf file tells the Sword engine how to treat installed module files, etc. which kind of markup they contain, and so forth.
Below is a listing of the possible directives in that file. Each of these directives of the form key=value. Some keys can be repeated. Some can have values that span more than 1 line with '\' at the end of a line indicating that the text on the next line continues the value. Some values allow RTF and some allow HTML <a href="xxx">label</a>hypertext links. HTML is not allowed otherwise.
Note on RTF, only the following are allowed:
- \qc - for centering
- \par - for paragraph breaks
- \pard - for resetting paragraph attributes, i.e. turning off centering.
- \q{num}? - for unicode characters, where {num} is a signed, 16-bit representation of the code point and where ? is the ASCII character used in case unicode is not supported. This should only be used in modules that have an Encoding=UTF-8, but using the actual UTF-8 character is preferred.
Enumerated values are shown in bold. These should be used exactly as given and no other values should be used.
| Element | Values (type or enumerated) | Default Value | Allows |
|---|---|---|---|
| Required Elements | |||
| [name] | Each conf file begins with [name], replacing "name" with be a short well known abbreviation. This must be on the first line, and start the first line. It can only contain A-Z, a-z and 0-9. The name of the file should be the lowercase of this name followed by .conf. For example, [MyModule] would be mymodule.conf. |
||
| DataPath | <relative system path>
DataPath is the path to the module relative to the SWORD module root directory. This path should start with "./modules". If the DataPath indicates a directory it should end with a '/'. Otherwise the module name is both the directory and the prefix for each file in that directory. Typical paths are for a module named [mymodule] are: ./modules/texts/rawtext/mymodule/ ./modules/texts/ztext/mymodule/ ./modules/comments/zcom/mymodule/ ./modules/comments/hrefcom/mymodule/ ./modules/comments/rawcom/mymodule/ ./modules/comments/rawcom4/mymodule/ ./modules/comments/rawfiles/mymodule/ ./modules/lexdict/zld/mymodule/mymodule ./modules/lexdict/rawld/mymodule/mymodule ./modules/lexdict/rawld/devotionals/mymodule/mymodule ./modules/lexdict/rawld/glossaries/mymodule/mymodule ./modules/lexdict/rawld4/mymodule/mymodule ./modules/genbook/rawgenbook/mymodule/mymodule But when it really comes down to it, a valid path could be: |
||
| Description | <string> This is a short (1 line) title of the module. |
||
| ModDrv |
RawText (for uncompressed Bibles) |
||
| Elements required for proper module access | |||
| CompressType | ZIP LZSS Used to indicate how a compressed modules (zText, zCom, & zLD) is compressed. ZIP is the preferred format. And as of today, no compressed modules use LZSS. |
LZSS | |
| BlockType |
BOOK Used for zText and zCom to indicate how much of the work is compressed into a block. The trade off is size for speed, with BOOK taking the least overall space and the longest time and VERSE taking the greatest overall space and the least time. While BlockType has a default, it is a best practice to specify it. Most Bibles use BOOK and larger Commentaries use CHAPTER. To date, no module uses VERSE. |
CHAPTER | |
| BlockCount | <integer> Used for zLD to indicate the number of entries in a compressed block. Higher values will make the module slower, but smaller. |
200 | |
| KeyType | TreeKey VerseKey |
TreeKey | |
| CipherKey | <string> Contains the unlock key for enciphered modules. A good key is something that is hard to guess. Typically in a format matching the pattern: /[0-9]{4}[A-Za-z]{4}[0-9]{4}[A-Za-z]{4}/. Internally the key can be any byte sequence from 1 to 255 bytes in length. But this file needs it to be readable, plain text, without leading or trailing spaces. Leave a blank line ("CipherKey=") to indicate that the module is enciphered but has no unlock key. (Omit for unlocked modules.) |
||
| Elements required for proper rendering | |||
| GlobalOptionFilter |
GBFStrongs (For GBF texts having Strong's Numbers) Each of these filters removes/hides the text's feature, when activated by the application. These filters are applied in the order that they are listed in the conf. |
Repeats | |
| Direction |
LtoR (Left to Right) Indicate whether the language's script is a left to right script or a right to left script. Languages such as Hebrew, Arabic, Urdu, Farsi have a RtoL script. When a module contains more than one direction, such as a Hebrew/English dictionary, set this value to BiDi. If the RtoL script is transliterated into a LtoR script, set the value to LtoR. |
LtoR | |
| SourceType |
Plaintext These are various ways that the text can be encoded. The preferred encoding is OSIS. TEI is preferred for dictionaries until OSIS supports dictionaries. In SWORD, for modules encoded with ThML, OSIS or TEI, each verse, dictionary entry, and book division needs to be well-formed XML or it will result in display problems in some frontends. |
Plaintext | |
| Encoding |
UTF-8 The preferred encoding of texts is UTF-8. Latin-1 is defined by Windows Codepage 1252 (cp1252) which is a superset of ISO 8859-1. This encoding indicates how the conf and the module are encoded. Warning: "Latin-1" is an ambiguously used term. See ISO 8859-1 at Wikipedia for technical details; in reality Latin-1 is regularly used as a synonym for ISO-8859-1. Frontend implementors should use "cp1252" or "windows1252" explicitly, not "Latin-1" provided by some programming language libraries. |
Latin-1 | |
| DisplayLevel | <integer> | 1 | |
| Font | <string> Specify the font to be used for display of the module if it is available. Omit this line to use the default font. Do not make use of font-specific encodings in your documents, but use Unicode instead and the Private Use Area if necessary for codepoints that are not handled by Unicode. |
||
| OSISqToTick | true/false When set to false indicates that OSIS quote elements without a marker attribute are not to produce a quotation mark. This is useful for languages (e.g. Thai) and texts (e.g. KJV) that do not have quotation marks. It is also useful for modules that mark the "Words of Christ" on a verse by verse basis, when the quote spans more than one verse. |
true | |
| Elements to indicate features | |||
| Feature |
StrongsNumbers (for modules that include Strong's numbers) |
Repeats | |
| GlossaryFrom | <xml:lang identifier> Glossaries map one language to another. This value indicates the language being translated from. See Lang below for a discussion of valid values. |
||
| GlossaryTo | <xml:lang identifier> Glossaries map one language to another. This value indicates the language being translated to. See Lang below for a discussion of valid values. |
||
| General informatic and installer elements | |||
| About | <string> A lengthier description and may include copyright, source, etc. information, possibly duplicating information in other elements. |
Continuation RTF |
|
| Version | <version string> Gives the module's revision number. Incrementing it when changes are made alerts users of the SWORD Installers to the presence of updated modules. Please start with version 1.0 and increment by 0.1 for minor updates and by larger values for more major updates such as a new text source. Changes to this conf file should also increment the version number. Do not use non-numbers, such as 1.4a or 1.1.3. |
1.0 | |
| History_x.x | <string> Used to alert users to what has changed between different versions. Each time a version is incremented a history line with that version number should explain the change. |
Repeats | |
| MinimumVersion | <version string> Identifies the minimum version of the Sword library required for this module. |
1.5.1a | |
| Category |
Daily Devotional (for modules with Feature=DailyDevotion) |
Biblical Texts (for /(Raw|z)Text4?/) Commentaries (for /(Raw|z|HREF)Com4?/) |
|
| LCSH | <tree/string> Library of Congress Subject Heading. You may search the Library of Congress catalog or use it as a guide for determining an appropriate LCSH for books that are not in the Library of Congress. |
||
| Lang | <xml:lang identifier> This is the primary language code of the module and should include a value according to RFC 4646 using ISO639 codes when possible. ISO 639-1 codes are the preferred code (e.g. en for English). If there is none for the given language, use an ISO 639-2/T code (e.g. ceb for Cebuano). Failing that, use ISO 639-3, which covers over 7000 languages. See: http://www.sil.org/iso639-3/codes.asp for ISO 639-1, 639-2/T and 639-3 codes. |
en | |
| InstallSize | <integer (indicating bytes)> | ||
| SwordVersionDate | <ISO date string (yyyy-mm-dd)> Indicates the date that the module was changed. | ||
| Obsoletes | <name of module> Each instance of this element names a module that is made obsolete by this module, usually indicated by the former name of the module. |
Repeats | |
| Copyright & Licensing related elements | |||
| Copyright | <string> Contains the copyright notice for the work, including the year of copyright and the owner of the copyright. |
Continuation | |
| CopyrightHolder | <string> Contains the name of the copyright holder. |
||
| CopyrightDate | <integer (indicating year)> | ||
| CopyrightNotes | <string> | Continuation | |
| CopyrightContactName | <string> Contains the name of the copyright holder. |
Continuation | |
| CopyrightContactNotes | <string> | Continuation | |
| CopyrightContactAddress | <string> Contains the mailing address of the copyright holder. |
Continuation | |
| CopyrightContactEmail | <string> Contains the email address of the copyright holder, preferably in the form: name at xyz dot com. |
||
| ShortPromo | <string> A link to the home page for the module, perhaps with an encouragement to visit the site. |
HTML Link | |
| ShortCopyright | <string> | ||
| DistributionLicense |
Public Domain In the event you use a text licensed as "GPL", use "Creative Commons: by-sa". This captures the spirit of the GPL using license terms that can actually apply to a text document. |
||
| DistributionNotes | <string> Indicates any additional notes about distribution of the module. |
Continuation | |
| TextSource | <string, probably a URL> Indicates, either in prose (such as "CCEL") or as a URL of the source of the text |
Continuation | |
Creating a module
The SWORD Project currently requires that all submitted texts be Unicode (specifically UTF-8) encoded documents. We recommend that texts be marked up in OSIS, but will still accept those marked up in either ThML or GBF. TEI is currently under development for Dictionaries.
Preparing a Text for Import
Encoding
For English language texts that only make use of ASCII characters, no change to the source encoding will be required. For other European language and most other languages, there probably exist simple encoding converters for ISO and national standards to UTF-8. For more complex source encodings, you may need to create your own converter or adapt an existing one. Some currently available conversion tools that you may find useful, depending on your platform and needs, include:
uconv (part of ICU), available compiled for Win32 at http://crosswire.org/ftpmirror/pub/sword/utils/win32/uconv.zip or in source format from ICU at http://oss.software.ibm.com/icu/. font2uni from CCEL, available at http://www.ccel.org/info/gkheb/.
uconv is best suited for standard encodings and font2uni is best suited for font-specific encodings. When creating XML texts, the only entities that should be used are & for '&' and < for '<'. All other entities should be encoded as their UTF-8 equivalents.
Markup
Internally, SWORD can process text in one of four formats: OSIS, TEI, ThML, and GBF. From these formats, it can convert to other formats, including RTF and HTML, for display. OSIS 2.1 is now the preferred format for Bibles and commentaries. At the moment OSIS does not have thorough support for complex dictionaries. For that reason we support TEI for dictionaries.
You may find documentation for each of these standards at their respective websites:
- Open Scriptural Information Standard (OSIS) : http://www.bibletechnologies.net/
- Text Encoding Initiative (TEI) : http://www.tei-c.org/P4X/DI.html
- Theological Markup Format (ThML) : http://www.ccel.org/ThML/
- General Bible Format (GBF) : http://www.ebible.org/bible/gbf.htm
In SWORD, for modules encoded with ThML and OSIS, each verse, dictionary entry, and book division needs to be well-formed XML or it will result in display problems in some frontends. SWORD only handles the subset of the ThML tags that we have found necessary, but we are willing to supporting additional tags, as the need arises.
Supported ThML tags include: <sync> (with type parameters of Strongs, morph, & lemma), <scripRef>, and <note> (plus closing tags where appropriate). HTML tags that ThML inherits, which may be used in SWORD modules include <div> (with types of sechead for section headings and title for titles, <i>, <br>, and <b>. Additional HTML tags may be interpreted by those SWORD frontends that render HTML, but will not be translated to RTF for the Win32 frontend.
GBF is deprecated and no GBF modules will be accepted by the SWORD Project. Supported GBF tags include: <WG>, <WH>, <WTG>, <WTH>, <RX>, <RF>, <FI>, <FB>, <FN>, <FR>, <FS>, <FU>, <FO>, <FV>, <CA>, <CL>, <CG>, <CM>, <CT>, <JR>, <JC>, <JL>, <TT>, and <TS> (plus closing tags where appropriate). In addition, SWORD allows full use of UTF-8 rather than merely ASCII as the GBF standard specifies.
Import formats
ThML and OSIS Formatted General Books
With ThML and OSIS formatted general books, provided your document is well-formed and valid XML according to the ThML DTD or the OSIS 2.1 Schema, you should not need to do any further processing. You can use your XML file with thml2gbs and xml2gbs. For OSIS encoded Bibles use osis2mod.
vpl Format
vpl or verse-per-line format may only be used in creating Bibles. This format requires that each line start with a verse reference that SWORD can understand, such as "Genesis 1:1" or "Jn 3:16". Most English abbreviations are acceptable. Following the verse reference, the verse itself should be written, in any kind of markup. For example:
Genesis 1:1 In the beginning God created the heaven and the earth. Genesis 1:2 And the earth was without form, and void; and darkness was upon the face of the deep. And the Spirit of God moved upon the face of the waters.
This format is used with the utility vpl2mod, discussed below. To import Bibles that have have combined verses, you will need to use imp format, instead of vpl.
imp Format
The imp or import format is the most versatile of the import formats and may be used in creating all types of modules (Bibles, commentaries, dictionaries, daily devotionals, glossaries, general books, etc.) in any supported format (GBF, ThML, OSIS or TEI). Each entry in an imp file may take as many lines as are needed. The first line of the entry will have a format such as "$$$<key>" and will be followed by all lines of text that should be included with that entry. So our above example in imp format would be written as:
$$$Genesis 1:1 In the beginning God created the heaven and the earth. $$$Genesis 1:2 And the earth was without form, and void; and darkness was upon the face of the deep. And the Spirit of God moved upon the face of the waters.
Commentaries would follow the same format, but would probably include a greater number of lines of text. If your Bible or commentary uses a single entry to handle multiple verses, simply give a list or range of verses as the key (e.g. "$$$Genesis 1:1-5", "$$$Exodus 1", "$$$Leviticus 1:1,5"). Lexicons, dictionaries, glossaries and daily devotionals would take a form such as:
$$$Adam Adam was the first man created by God. $$$Eve Eve was the first woman created by God.
For daily devotionals, you must encode the key as "$$$mm.dd", such as "$$$01.01" for January 1st and "$$$12.31" for December 31st.
General books are encoded with each book division as a separate entry. The entries are then listed as a tree hierarchy with keys similar to a file system directory structure. For example, if you were encoding the Josephus' Works, you might have a structure like this:
$$$/War The War of the Jews $$$/War/Book 1 Book 1 of the War of the Jews $$$/War/Book 1/Chapter 1 Chapter 1 of Book 1 of the War of the Jews $$$/War/Book 1/Chapter 1/Section 1 Section 1 of Chapter 1 of Book 1 of the War of the Jews $$$/War/Book 1/Chapter 1/Section 2 Section 2 of Chapter 1 of Book 1 of the War of the Jews
Importing
Now that your text is ready to be imported, you will need to use one of the command line utilities for converting documents to SWORD format. Depending on the format of your document at this point, you will need to use the appropriate importer.
- If your text is a valid ThML document, use thml2gbs.
- If your text is a valid OSIS Bible, use osis2mod.
- If your text is a valid OSIS document, use xml2gbs.
- If your text is a vpl format Bible, use vpl2mod.
- If your text is an imp format Bible or commentary, use imp2vs.
- If your text is an imp format dictionary, lexicon, glossary, or daily devotional, use imp2ld.
- If your text is an imp format general book, use imp2gbs.
You may find these files in the SWORD Project source distribution or compiled for Win32 at http://crosswire.org/ftpmirror/pub/sword/utils/win32/. Each utility has brief usage information that can be viewed by running it once without any arguments.
Additional Utilities
There are additional utilities that may be used on SWORD modules:
Compressing Modules
To compress a Bible, commentary, or LD module, use the mod2zmod utility. First you will need to install the module so that it can be accessed using the SWORD engine. Next, run:
mod2zmod <modname> <datapath> [blockType [compressType]]
blockType can be 4 = book (default), 3 = chapter, or 1 = verse and indicates the granularity of the compression blocks. The larger the block is, the longer it will take to access a piece of the text, but the smaller the resulting module will be. compressType can be either 1 = LZSS (default) or 2 = Zip.
You may wish to try different compression settings to find out which is best for your module. Typically, we use chapter compression for large commentaries, book compression for Bibles, and the Zip compression algorithm.
Locking Modules
To lock a rawText Bible or rawCom commentary module, use the cipherraw utility. Just run:
cipherraw </path/to/module> '<key>'
Checking for Missing Verses
You can use the utility emptyvss to find verses in a module that contain no text, since this may indicate errors in the module. Just run:
emptyvss <module name>
on an installed module to generate a list.
Miscellaneous tools
Further miscellaneous tools that are 'not ready for public consumption' but may be useful to modules authors are found in DevTools:Misc. These includes scripts and programs that are used for the preparation and conversion of various specific modules.
Submitting content to the SWORD Project
After you have tested your module, you may wish to submit it to the SWORD Project for public release so that other people can benefit from your work. All modules submitted to the SWORD Project for distribution either on the internet or on CDs should include both the module as a single document and the .conf file.
The module itself should be an uncompiled, plain text document in either vpl (verse-per-line), imp (import), ThML, OSIS or TEI format, ready to be run through one of the import tools.
Before any module will be considered for posting, we expect that the following minimum set of tags be included in its .conf file: DataPath, ModDrv, Lang, Description, About, DistributionLicense, and TextSource. We also strongly prefer that an LCSH line be included with the .conf file, but will look the LCSH up ourselves if you have trouble deciding on a value. (You can look at other .conf files for examples.)
When you feel your module is ready to be submitted, you may email it to modules@crosswire.org. If you are unable to email it or would prefer to send the files by some other means, you may contact us at the same email address, and we can discuss other arrangements.
