The following table summarizes FOP's standard hyphenation support. Please note that the "view" links reflect current CVS, and may be different than the contents of released code. See Hyphenation Patterns for a brief explanation of the contents of these files.

If you would like to build your own hyphenation pattern files, or modify existing ones, this section will help you understand how to do so. Even when creating a pattern file from scratch, it may be beneficial to start with an existing file and modify it. See Standard Hyphenation Support or the source distribution (src/hyph) for examples. Here is a brief explanation of the contents of FOP's hyphenation patterns:

• The root of the pattern file is the <hyphenation-info> element.
• <hyphen-char>: its attribute "value" contains the character signalling a hyphen in the <exceptions> section. It has nothing to do with the hyphenation character used in FOP, use the XSLFO hyphenation-character property for defining the hyphenation character there. At some points a dash U+002D is hardwired in the code, so you'd better use this too (patches to rectify the situation are welcome). There is no default, if you declare exceptions with hyphenations, you must declare the hyphen-char too.
• <hyphen-min> contains two attributes:
  • before: the minimum number of characters in a word allowed to exist on a line immediately preceding a hyphenated word-break.
  • after: the minimum number of characters in a word allowed to exist on a line immediately after a hyphenated word-break.
  This element is unused and not even read. It should be considered a documentation for parameters used during pattern generation.
• <classes> contains whitespace-separated character sets. The members of each set should be treated as equivalent for purposes of hyphenation, usually upper and lower case of the same character. The first character of the set is the canonical character, the patterns and exceptions should only contain these canonical representation characters (except digits for weight, the period (.) as word delimiter in the patterns and the hyphen char in exceptions, of course).
• <exceptions> contains whitespace-separated words, each of which has either explicit hyphen characters to denote acceptable breakage points, or no hyphen characters, to indicate that this word should never be hyphenated, or contain explicit <hyp> elements for specifying changes of spelling due to hyphenation (like backen -> bak-ken or Stoffarbe -> Stoff-farbe in the old german spelling). Exceptions override the patterns described below. Explicit <hyp> declarations don't work yet (patches welcome). Exceptions are generally a bit brittle, test carefully.
• <patterns> includes whitespace-separated patterns, which are what drive most hyphenation decisions. The characters in these patterns are explained as follows:
  • non-numeric characters represent characters in a sub-word to be evaluated
  • the period character (.) represents a word boundary, i.e. either the beginning or ending of a word
  • numeric characters represent a scoring system for indicating the acceptability of a hyphen in this location. Odd numbers represent an acceptable location for a hyphen, with higher values overriding lower inhibiting values. Even numbers indicate an unacceptable location, with higher values overriding lower values indicating an acceptable position. A value of zero (inhibiting) is implied when there is no number present. Generally patterns are constructed so that valuse greater than 4 are rare. Due to a bug currently patterns with values of 8 and greater don't have an effect, so don't wonder.
  Here are some examples from the English patterns file:
  • Knuth (The TeXBook, Appendix H) uses the example hach4, which indicates that it is extremely undesirable to place a hyphen after the substring "hach", for example in the word "toothach-es".
  • .leg5e indicates that "leg-e", when it occurs at the beginning of a word, is a very good place to place a hyphen, if one is needed. Words like "leg-end" and "leg-er-de-main" fit this pattern.
  Note that the algorithm that uses this data searches for each of the word's substrings in the patterns, and chooses the highest value found for letter combination.

If you want to convert a TeX hyphenation pattern file, you have to undo the TeX encoding for non-ASCII text. FOP uses Unicode, and the patterns must be proper Unicode too. You should be aware of the XML encoding issues, preferably use a good Unicode editor.

Note that FOP does not do Unicode character normalization. If you use combining chars for accents and other character decorations, you must declare character classes for them, and use the same sequence of base character and combining marks in the XSLFO source, otherwise the pattern wouldn't match. Fortunately, Unicode provides precomposed characters for all important cases in common languages, until now nobody run seriously into this issue. Some dead languages and dialects, especially ancient ones, may pose a real problem though.

If you want to generate your own patterns, an open-source utility called patgen is available on many Unix/Linux distributions and every TeX distribution which can be used to assist in creating pattern files from dictionaries. Pattern creation for languages like english or german is an art. If you can, read Frank Liang's original paper "Word Hy-phen-a-tion by Com-pu-ter" (yes, with hyphens). It is not available online. The original patgen.web source, included in the TeX source distributions, contains valuable comments, unfortunately technical details obscure often the high level issues. Another important source is The TeX Book, appendix H (either read the TeX source, or run it through TeX to typeset it). Secondary articles, for example the works by Petr Sojka, may alos give some much needed insigth into problems arising in automated hyphenation.