‫סבל‬

SBL Hebrew
Font User Manual

Font version .

Manual version .03, July 2005

Prepared by John Hudson, Tiro Typeworks,

for the Society of Biblical Literature

© John Hudson, 2003 & 2005

SBL Hebrew is a trademark of the Society of
Biblical Literature

Manual version .03 It is recommended that all users of the SBL Hebrew font read this
July 2005 manual carefully, even if they have used earlier versions of the font
and are familiar with encoding requirements and layout behaviour
discussed in earlier versions of the manual. There are a number of
important changes in the recommended encoding of some char-
acters, some of which may require updates to existing documents
made with earlier versions of the font. Since the first public version
of the font shipped in 2003, there have been a number of clarifica-
tions and additions to the Unicode codepoint range for Hebrew. The
latest version of the font, v., supports all Hebrew characters in
the recently released version 4. of the Unicode Standard. This ver-
sion of Unicode provides a couple of important additions for Biblical
Hebrew (notably, a codepoint for nun hafukah, allowing deprecation
of the hack used to access this as a glyph variant in previous versions
of the SBL Hebrew font). Discussions with members of the Unicode
Technical Committee and other interested parties have also clarified
the recommended encoding for the upper and lower puncta extraor-
dinaria and other marks. Sections of this manual that relate to such
additions or other changes from the behaviour of previous font ver-
sions are marked with a red line in the right margin, thus.

2
 Getting started If you have not already downloaded the latest version of the SBL He-
brew font, you should do so now. See page 22 for download informa-
tion and links to other useful websites.
Please take some time to review this manual. SBL Hebrew is a
complex font that makes use of new technologies that may be un-
familiar to you if you have not worked with Unicode encoded text
or font files before. Many of the lessons you may have learned from
using other Biblical Hebrew fonts and software may not apply, and it
may be necessary to develop some new work habits.

Installation The SBL Hebrew font is designed for use primarily with Windows
2000, Windows XP and later Microsoft operating systems. It may
also be used cross platform in applications that natively support ap-
propriate Unicode text processing and OpenType Layout. To install
the font on a Windows system, open the Fonts folder and drag and
drop the SBL_Hbrw.ttf file onto the folder. The Fonts folder can be
opened either by navigating in Windows Explorer to
c:\Windows\Fonts
(where c: is the root folder containing your Windows system files), or
by opening the Fonts folder from the Control Panel, accessible from
the Start button Settings menu.
The SBL Hebrew font can also be installed on older versions of
Windows, but because the font uses a pure Unicode encoding, not an
8-bit codepage, it may not work consistently in all applications.
It is also possible to install the font on Linux and other open
source systems using the FreeType library, and on Mac OS X. Please
see pages 7–8 for information about support on non-Windows
systems.

File name and icon Although SBL Hebrew is an OpenType format font, it has a .ttf file
name extension and will display the regular TrueType icon, rather
than the distinctive OpenType icon. The .ttf extension allows the
font to be recognised on older versions of Windows (although these
only support unvocalised Hebrew text). The regular TrueType icon is
displayed only because the font does not contain a digital signature.
Note that the different icons available for TrueType OT fonts do not
indicate anything about the presence or absence of OpenType Lay-
out tables for glyph substitution or positioning, both of which are
present present in the SBL Hebrew font. See pages 4–5 for more in-
formation.

3
 Introduction Most fonts do not come with user manuals, and most do not need
them. SBL Hebrew is a complex font that uses new encoding and
layout technologies, and this manual explains these technologies
to help you get the most out of your new font. This manual also
discusses known issues relating to these technologies, particularly
current levels of operating system and application support, and the
complicated but important issue of text normalisation. Although
you can install the SBL Hebrew font on most current operating sys-
tems, and can immediately begin working with it, please take time
to review this document. Understanding issues like optimal charac-
ter ordering will help ensure that the SBL Hebrew correctly displays
your text.

The font format SBL Hebrew is a TrueType-flavour OpenType font.

This section is probably the The original TrueType font format was developed by Apple Com-
least essential reading in this puters and released in the early 990s. It was quickly licensed by Mi-
manual. This section explains crosoft Corp. and is the system font format for Apple and Microsoft
the background to the develop- operating systems (the packaging of the format differed on the two
ment of the technology used systems prior to the introduction of Apple’s Mac OS X, which can
in the SBL Hebrew font, and install Windows TT fonts). A TrueType font is a collection of tables,
explains exactly what kind of each containing information specific to a particular aspect of the
font this is in technical terms. font. For example, the glyf table contains outline information, the
cmap table maps glyphs in the font to character codes for text entry
and storage, and so forth.
The OpenType font format is an extension of the TrueType for-
mat, jointly developed by Microsoft Corp. and Adobe Systems. An
OpenType font has the same table structure as a generic TrueType
font, but with the option to include additional tables. There are two
key components to the OpenType extensions: PostScript outline
data and OT Layout data. The first of these determines the ‘flavour’
of a font—that is, the kind of outline and rendering technology
used to ‘paint’ text. As noted above, SBL Hebrew is TrueType-fla-
vour, meaning that it uses the original TrueType outline format and
rendering technology rather than PostScript. The second key compo-
nent, OpenType Layout data, is essential to the correct rendering of
complex scripts like Hebrew, and much of this manual is concerned
with this technology and how it renders Biblical Hebrew. The SBL
Hebrew font contains two kinds of OpenType Layout data: glyph
substitution and glyph positioning. These are stored in the Open-
Type optional tables GSUB and GPOS.
For these and other online For more information about the OpenType font format, see the
documents, please see the list specification and other material on the Microsoft or Adobe websites.
of URLs in Appendix C, p.22 The Microsoft introductory essay Windows Glyph Processing, which
also discusses other aspects of complex script shaping referred to in
4
 this manual, might be a good place to start. None of this material is
essential to being able to use the SBL Hebrew font, but it will help
you better understand that technologies on which the font relies.

Unicode text encoding The SBL Hebrew font uses standard Unicode character codes to en-
This section explains, in code Hebrew letters and marks. Unicode is an international charac-
simplified terms, what the ter encoding standard that provides a single unique code for every
Unicode Standard is, and the semantic character necessary to encode plain text in supported
implications of this encoding scripts and languages. Today, most of the world’s major scripts and
standard for Biblical Hebrew languages are supported by Unicode, and recent efforts have led to
and for users of the SBL the encoding of numerous historical scripts. Because every character
Hebrew font. in Unicode has a unique code, rather than sharing codes across mul-
tiple codepages or being assigned to different codes e.g. on Windows
and Mac operating systems, text encoded in Unicode can be safely
exchanged between different operating systems and applications
that employ Unicode. The benefit of such a standard to scholarship,
where authors and publishers are often using different software,
should be obvious.
An 8-bit encoding is one In the past, Hebrew text was supported on different platforms,
that uses a single byte of and even between different applications, using a variety of stand-
computer memory or storage ard and not-so-standard 8-bit encodings. Because the fonts that
for each character in text. 8-bit supported these encodings tended to be ‘dumb’ fonts, i.e. without
encodings are limited to 256 built-in layout intelligence, often multiple fonts would be needed
characters, which explains the to correctly display complex texts such as found in Biblical schol-
need for multiple encodings. arship. This, of course, increased the likelihood that text produced
with these encodings could not be reliably and accurately exchanged
between systems and applications, because correct display relied on
not only knowing which encoding standard was used but also which
font was used where. Unicode and OpenType solve these problems
by using a unique code for each Hebrew consonant and mark, and
employing layout intelligence to map from the encoded characters
to the appropriate arrangement of glyphs to display a given text.
[See the examples on the following pages.]
While the benefit of Unicode is easy to see, it does require that the
SBL Hebrew font be used in a Unicode text encoding environment,
i.e. in systems and applications that use Unicode character codes
when storing, manipulating and displaying text. The font does not
contain an 8-bit codepage—only Unicode—so no guarantees can be
made about its performance in non-Unicode environments, [Note,
however, that some applications will internally map from Unicode
characters in a font to 8-bit codes used internally by the application.
In this case some text may display correctly with the SBL Hebrew
font, although the text remains subject to the typical exchange prob-
lems of 8-bit text.] It may be that your current document publish-
5
 ing workflow involves non-Unicode applications, and this will limit,
for the time being, the usefulness of the SBL Hebrew font in your
work. During the past few years, Unicode has become the dominant
encoding standard for most major operating systems, and is, for ex-
ample, specified by the World Wide Web consortium as the default
encoding of XML documents. It is very likely that the makers of your
present software will be updating their applications to handle Uni-
code, and they may be able to give you estimates on when suitable
upgrades will be available. If you are tied to software that is not be-
ing updated to handle Unicode soon, or if you simply cannot wait
and like the design of the SBL Hebrew typeface, it may be possible to
arrange to have custom fonts made for specific 8-bit encodings, or to
make your own. For information on the kind of modifications that
are permitted, or for contact information, please see the font license
in Appendix A, page 9.

Uniscribe The layout intelligence in OpenType fonts relies on system or appli-

This section explains the role cation support for basic linguistic shaping. In simple terms, systems
of the Microsoft Unicode and applications deal with characters, and fonts deal with glyphs, i.e.
Script Processor (Uniscribe) in with the visual representation of characters. Complex scripts like
shaping complex scripts. The Hebrew require systems and applications to be aware of right-to-left
most important thing to note and bidirectional layout and of character properties that distinguish
in this regard is that different e.g. consonants from combining marks. Some applications will have
versions of Uniscribe will built in support for such things, while others will rely on standard
produce different results for system components. Microsoft’s Unicode Script Processor—com-
some Hebrew mark sequences. monly referred to as Uniscribe—is a standard system component
that includes shaping engines for various scripts, including Hebrew.
Uniscribe works directly with OpenType fonts, such as SBL Hebrew,
built according to Microsoft specifications. An application that uses
Uniscribe will make calls to it as text is entered and edited; Uniscribe
processes the input characters, and applies the layout intelligence in
the font accordingly.
Note that applications using If you are using an application that utilises Uniscribe—these
text processing calls on systems include the Microsoft Office Suite on Windows, Internet Explorer,
older than Windows 2000 may and any other app that makes standard system calls for text input
not be Uniscribe clients. and output—you will find working with Biblical Hebrew text very
easy and the SBL Hebrew font will automatically correctly display
most text. I say most text, because there is always the possibility
to create sequences of consonants plus marks that are linguistically
non-standard and which cannot be correctly resolved by the layout
features in the font. The SBL Hebrew font has been tested with every
This document is also available combination of consonant plus mark(s) that occurs in the Michigan-
from http:www.tiro.com/ Claremont Old Testament text. The results of this testing are avail-
resources/hebrew/ able as a 2-page Acrobat document from the Society of Biblical
6
 Literature Hebrew font website. The document shows every unique
consonant plus mark(s) sequence that occurs in the text along with
following consonant context.
Software developers producing Different versions of Uniscribe ship with and are used by different
software for use in Biblical applications and system versions, which means that rendering re-
scholarship can arrange for sults may vary. We have been fortunate, during the development of
a redistribution license for SBL Hebrew, to test the fonts with unreleased versions of Uniscribe
Uniscribe. This enables them that will ship with upcoming software. The new versions of Uniscribe
to bundle more recent versions have been used to confirm that all consonant plus mark(s) sequenc-
of Uniscribe for utilisation by es in the Michigan-Claremont text will be correctly rendered when
their software. Contact these versions of Uniscribe are employed. Because SBL Hebrew has, in
Microsoft Typography for more this respect, been designed for next generation technology, some
information. sequences will display incorrectly in systems and applications using
older versions of Uniscribe. It is important to note that these se-
quences may be correctly encoded, and that documents with display
problems are not erroneous. Typically, when a sequence of marks
cannot be correctly rendered by Uniscribe, the shaping engine will
insert a dotted-circle, and the mark or marks that cannot be applied
to the preceding consonant will be applied to the circle. The example
below shows three possible levels of display for a unique sequence
of consonant plus marks from Job 7: (alefalef + hataf patah + meteg +

�ֽ֭ �� �� ��
�‫א‬
�ֲ
dehi).

C. Incorrect B. Incorrect A. Correct

A. This example shows the correct rendering applied by Uniscribe

version .468.405.0, a recent beta version of Uniscribe. This and
all later versions of Uniscribe (including .47.4063.0, which ships
with MS Office 2003) can be expected to correctly render this and
other consonant plus mark sequences.
B. This example shows incorrect rendering applied by Uniscribe ver-
sion .325.280.; this is the version of Uniscribe that ships with
Windows 2000. As you can see, this version of Uniscribe is unable
to correctly apply dehi to a consonant that already carries a com-
bination of hataf vowel and meteg, so inserts a dotted circle.
C. This very incorrect example shows the same sequence crudely dis-
played by an application that does not use Uniscribe and cannot
implement the glyph positioning intelligence in the SBL Hebrew
7
 font. The marks are blindly centered below the consonant, but
they collide and do not interract correctly. In some applications,
the marks may not even be centered below the consonant, but will
cluster between it and the next letter.

Note that in the two examples rendered by Uniscribe the meteg com-
bines with the hataf patah, forming a mark ligature in which the me-
teg appears between the two parts of the vowel. For more informa-
tion about this and other aspects of meteg handling, see the section
of this manual on page 3.

The normalisation issue Although implementation of the Unicode Standard is generally a

This section explains an boon to scholars working with texts in complex scripts, there is an
important problem in the unfortunate and quite serious problem in the current encoding of
encoding of Hebrew in the Hebrew. This involves the canonical combining class assignments
Unicode Standard. This that are used when text is normalised. Normalisation is a process by
problem will not affect all text, which sequences of characters in text that can be variously encoded
but can be a serious problem but are semantically identical are treated as identically encoded. This
that users need to be aware of. can frequently involve the reordering of a sequence of characters.
Consider, as an example, this combination of consonant plus marks
that occurs in  Ch 3:3. This combination could be encoded in six

‫ֵ֕טּ‬
different ways, and each would result in exactly the
same visual representation and the same semantic
meaning for the reader:
. tet + dagesh + tsere + zaqef gadol
2. tet + dagesh + zaqef gadol + tsere
3. tet + tsere + dagesh + zaqef gadol
4. tet + tsere + zaqef gadol + dagesh
5. tet + zaqef gadol + dagesh + tsere
6. tet + zaqef gadol + tsere + dagesh
The SBL Hebrew font is able to correctly render any of these sequenc-
es (although most users familiar with Hebrew would agree that the
dagesh should, logically and linguistically, precede the vowel and the
cantillation mark, and most would also agree that the vowel should
precede the cantillation mark). If you consider that any combina-
tion of consonant plus three marks can be encoded in six different
ways, it is easy to realise how even a fairly short word of five or six
consonants with all their marks could be encoded in many dozens
of different ways. Normalisation is important because it provides a
mechanism for all these possible permutations of mark ordering to
be resolved to a single canonical order. This is most important when
a text not only needs to be displayed but also needs to searched,
sorted or spellchecked. If a search algorithm had to look for fifty
or more possible and equivalent spellings of a single word, it would
8
 Note that the Unicode be extremely inefficient and slow. So normalisation is applied to
Standard includes multiple reorder every equivalent sequence of characters into a single and
normalisation forms, i.e. consistent order.
different ways of normalising Normalisation is achieved by giving every mark a canonical com-
text, and not all of these bining class. This is a number that indicates how close to the base
involve reordering of marks. character (the consonant, in the case of Hebrew) each mark should
The form that is of concern for be ordered and which marks may be reordered relative to each
Biblical Hebrew encoding is other. Some canonical combining classes contain only individual
Normalisation Form C, which characters, indicating that these can always be reordered relative
does reorder marks. to characters with different classes; some classes contain multiple
characters, indicating that these cannot be reordered relative to each
other. If two or more characters are included in the same class, this
means that their relative ordering is semantically meaningful and
not equivalent; therefore, they must not be reordered or the mean-
ing will be lost.
So far, so good, but when the Hebrew script was encoded in the
Unicode Standard, combining classes were assigned in a way that
failed to take into account the many peculiarities of Biblical texts.
This has resulted in every Hebrew vowel being assigned its own ca-
nonical combining class, meaning that combinations of two vowels
applied to a single consonant may be reordered during normalisa-
tion. This is not a problem for modern Hebrew spelling, but can be
disastrous for Biblical texts due to textual conventions such as the
tendency to record changing pronunciation by applying new vocali-
sation but preserving the original consonant structure of words. A
For more thorough discusion of good—and important—example is the change in pronunciation of
this example, see Tov, Emanual. yerušālēm to yerušālayim, which required the Masoretes to add hiriq
Textual criticism of the between the lamed and the final mem in order to approximate the
Hebrew Bible. 2nd edition, new pronunciation as yerušālaim, while preserving the consonant
Minneapolis, 992. p43. structure of the ancient manuscripts. The final four characters of
this word are correctly encoded in the order lamed + patah + hiriq +
Here are the Hebrew words final mem, and the word is correctly displayed �‫רוּשׁ ַל‬ָ ְ‫ ; י‬however, the
from this example enlarged. faulty canonical combining classes for patah and hiriq in Unicode
Correct, before normalisation: cause hiriq to always precede patah when reordering due to normali-

�‫רוּשׁ ַל‬
ָ ְ‫י‬ sation is applied. The resulting sequence lamed + hiriq + patah + final
mem is textually incorrect, and it cannot be correctly displayed by
Inorrect, after normalisation: the SBL Hebrew font: ‫רוּשׁ ִַלם‬
ָ ְ‫( י‬note collision of vowels under lamed ).

‫רוּשׁ ִַלם‬
ָ ְ‫י‬ Unicode normalisation can easily break Biblical Hebrew text.
The good news is that most software does not automatically ap-
ply normalisation, and software developers familiar with Biblical
Hebrew are likely to be aware of the problem. There remains a risk,
however, especially when documents are being exchanged between
different platforms or published on the Internet, that a piece of soft-
ware beyond the original author or editor’s control—a web browser
9
 on the receiving end of an electronic document, for example—may
apply normalisation. This is, of course, not a font issue per se; it is
a text encoding issue that can affect any document and result in
textual error, incorrect display, or both. It is very likely that future
rendering engines for Hebrew may perform corrective mark order-
ing during rendering, to ensure that normalised sequences can be
correctly rendered by fonts built to a common specification. This will
remove many of the possible display problems associated with Uni-
code normalisation. However, there will remain a number of cases
in which the results of normalisation may display ‘correctly’ but in
which the meaning of the text is changed. For instance, if meteg is
positioned at the right side of a vowel, it may be moved to the left
side during normalisation: both positions will render correctly, but
only one is textually correct. So mechanisms are necessary to guard
against some mark reordering during normalisation.
Software developers who need to apply normalisation to text to
facilitate efficient searching can, of course, avoid the problems of the
Unicode mark reordering by using a custom normalisation routine
that does not reorder Hebrew vowels. Combining classes for such a
custom routine, based on the mark ordering recommendations of
the next section, are suggested in Appendix B, page 20. However,
this does not address the issue of Unicode normalisation being ap-
plied ‘downstream’ of document creation, e.g. in web browsers.
If you are using the Tiro The Unicode Technical Committee recommends the use of the
Biblical Hebrew keyboard Combining Grapheme Joiner (CGJ, U+034F) character as a control
v.2, you can insert the CGJ character to override mark reordering during normalisation, and the
character manually using the SBL Hebrew font has been updated to handle this mechanism. Us-
key combination [ctrl+alt+7]. ing this mechanism, the problem case of mark reordering discussed
If you are using the SIL Biblical on page 9 would be resolved by inserting the CGJ character between
Hebrew keyboard, you can the patah and hiriq marks: lamed + patah + CGJ + hiriq + final mem.
insert the CGJ character The CGJ character can be inserted between any two adjacent mark
using the key combination characters that may be subject to reordering during normalisation,
[shift+ctrl+alt+P] and will prevent this reordering from happening. Software develop-
ers are currently discussing ways in which this can be implement-
ed automatically, so that the burden is not on document authors
to identify situations in which mark reordering might occur and to
manually insert CGJ at these places. It may be some time before such
solutions become widely implemented.
If you are not concerned about mark reordering, e.g. because you
are working in a completely closed text environment that does not
See the last paragraph on page employ normalisation or which uses a custom normalisation rather
3 for additional examples than the Unicode one, you do not need to worry about the CGJ char-
of mark reordering and CGJ acter in this regard. If you are producing documents that may be
insertion. published to the Internet or in other circumstances in which you do
0
 not have control of normalisation, CGJ provides a means for you to
prevent unwanted reordering. If you are working with specific Bi-
ble passages, and are concerned about normalisation reordering of
marks, you may find it helpful to check the chapter and verse to see
what words may be affected in a way that changes the recommended
mark order discussed in the following sections of this manual. To
Many thanks to Eli Evans at assist in this, we will be producing a document for each Bible book,
Libronix for help in preparing identifying such words. These documents will be found online at
these documents. http:www.tiro.com/resources/hebrew
Note that not all mark reordering results in broken rendering or
textual ambiguity. As noted above, some rendering engines may cor-
rect reordering during display, further reducing the number of in-
stances in which CGJ needs to be inserted; the most important use
of CGJ is in instances where the reordered text may render ‘cleanly’
but where textually important distinctions are lost, e.g. where a me-
teg moves from one side of a vowel mark to another.

Mark ordering As discussed in the previous section, the SBL Hebrew font can cor-
This section discusses rectly display equivalent sequences of marks applied to consonants
recommended ordering for in different orders. The font cannot correctly display every possible
sequences of consonants with permutation, especially when more than two marks are involved,
multiple marks. This is one of but it seldom matters, for instance, whether a below vowel or above
the more important sections of cantillation mark is applied to a consonant first. That said, there are
this manual. many benefits to establishing consistent habits in ordering marks
when creating documents. By following the recommended mark or-
dering outlined in the table on the next page, you will avoid enter-
ing sequences that cannot be correctly displayed—unless, of course,
they are beyond the general ability of the SBL Hebrew font to render
the Old Testament text—, and you will also make searching for
Hebrew words and phrases easier for yourself and colleagues with
whom you exchange electronic documents.
The basic principles of the mark ordering recommendation is that
marks affecting the pronunciation of consonants are applied first;
then the holam mark; then below marks, vowels and consonants, as
they occur from right-to-left except the prepositive marks yetiv and
dehi, which are applied after other low marks because they are po-
sitioned relative to them; then above marks, including metatextual
marks such as the masora circle, as they occur from right-to-left ex-
cept the postpositive marks pashta, telisha qetana and zinor. The table
of marks on the next page shows the order in which they should be
entered (note that this corresponds, also, to the recommendations
for custom normalisation in Appendix B, page 20).


 Table 
Recommended mark ordering  Base consonant ‫ש‬ 7 Prepositive below marks
2 shin dot �
‫ׁש‬ from the following group:
sin dot ‫ׂש‬
� yetiv ‫֚ש‬
3 dagesh/mapiq �
‫ּש‬ dehi ‫֭ש‬
4 rafe ‫ֿש‬ 8 Above marks from the
following group as they
5 holam ֹ‫ש‬ occur from right-to-left:
6 Below marks from the shalshelet ‫֓ש‬
following group as the occur zaqef qatan ‫֔ש‬
from right-to-left:
zaqef gadol ‫֕ש‬
sheva ‫ְש‬ revia ‫֗ש‬
hataf segol ‫ֱש‬ zarqa ‫֘ש‬
hataf patah ‫ֲש‬ qarney para ‫֟ש‬
hataf qamats ‫ֳש‬ gershayim ‫֞ש‬
hiriq ‫ִש‬ geresh muqdam ‫֝ש‬
tsere ‫ֵש‬ geresh ‫֜ש‬
segol ‫ֶש‬ telisha gedola ‫֠ש‬
patah ‫ַש‬ iluy ‫֬ש‬
qamats (gadol) ‫ָש‬ qadma (azla) ‫֨ש‬
qamats qatan ‫ׇש‬ ole ‫֫ש‬
qubuts ‫ֻש‬ pazer ‫֡ש‬
meteg ¹ ‫ֽש‬ masora/number dot ³ ‫̇ש‬
atnah ‫֑ש‬ high punctum extra.² ‫ׄש‬
atnah hafukh ‫֢ש‬ masora circle ⁴ ‫֯ש‬
tipeha ‫֖ש‬
9 Postpositive above marks
tevir ‫֛ש‬ from the following group:
munah ‫֣ש‬ segolta ‫ש‬
֒
mahapakh ‫֤ש‬ pashta ‫֙ש‬
merkha ‫֥ש‬ telisha qetana ֩‫ש‬
merkha kefula ‫֦ש‬ zinor ‫֮ש‬
darga ‫֧ש‬
yerah ben yomo ‫֪ש‬
low punctum extra.² ‫ׅש‬

Notes:
. See page 3 for specific information about meteg ordering.
2. See page 4 for specific information about puncta extraordinaria. Note that the
high punctum is centered above the letter and above any other high marks; it
should usually be ordered last of the marks in its group. Similarly the low punc-
tum should usually be ordered after other below marks.
3. See page 5 for specific information about the masora/number dot.
4. Although it may visually be positioned slightly to the right of other above
marks, the masora circle is usually ordered after any other marks in this
group. See page 5 for specific information about masora circle handling.

2
 Meteg handling The Hebrew mark meteg can appear in a variety of positions relative
This section explains the vari- to other below marks, and all these are supported in the SBL Hebrew
ous ways in which the meteg positioning lookups. However, not all are equally well supported in
mark can be applied and the applications at the time of writing. This section explains how to
expected results. encode sequences of consonant plus meteg with other marks to
achieve different visual results, and shows how these will be ideally
rendered.
The normal position of meteg relative to vowel marks is to the
left, e.g. ‫( ַ ֽו יִּ ְמ ְצ ֗אוּ‬ Kings :3). Such a sequence is encoded consonant +
vowel + meteg, that is, as the marks are ordered from right to left.
Much less commonly, meteg can appear to the left of a cantilla-
tion mark, e.g. ‫( ֲע ָב ִ ֑דֽים‬Ex 20:2). Again, this sequence is encoded as
the marks are ordered from right to left: consonant + vowel + cantil-
lation + meteg.
When meteg is applied to a consonant bearing a hataf vowel (hataf
segol, hataf patah or hataf qamats), the default font rendering is also
for the meteg to be positioned to the left of the vowel, e.g. ‫ֽיוֹת־א ְה יֶ ֥ ה‬ ֶֽ ‫ֱה‬
(Ps 50:2). However, it is common for this mark combination to be
displayed with a medial meteg positioned between the two parts of
the hataf vowel, e.g. ‫�ה ֶ֔יכם‬ ֵ ‫( �א‬2 Chr 32:5). This is handled by the SBL
Hebrew font, using an OpenType ligature substitution, when the
Zero Width Joiner (ZWJ, U+200D) control character is inserted be-
tween the hataf vowel and the meteg: consonant + hataf vowel + ZWJ
+ meteg.
Finally, there are those instances in which meteg needs to be
placed to the right of a vowel. These are relatively common on the
first consonant of a word in the Biblia Hebraica Stuttgartensia text,
e.g. �֣ ֥ ‫ה־ל‬
ְ ‫( ֽ ַת ֲע ֶ֨שׂ‬Ex 20:4), but may also occur in mid-word, e.g. ‫וְ ַלֽ ַנּ ֲע ָר ֙ה‬
(Deut 22:26). In such cases, meteg should be encoded before the vow-
el, i.e. as the marks are ordered from right to left: consonant + meteg
+ vowel. Note that this ordering should also be used in those rare
cases where meteg occurs to the right of a hataf vowel, e.g. ‫ֹא־א ָתּה‬ ֭ ַ ‫ֽ ֲהל‬
(Psa 85:7).
Note that because of the canonical combining class assigned by
Unicode to the meteg character, it may be subject to reordering dur-
ing normalisation (see pages 8–). For instance, the example from
Exodus 20— 20—֣�֥ ‫ה־ל‬ ְ ‫— ֽ ַת ֲע ֶ֨שׂ‬would be reordered during normalisation
such that the meteg shifts to the left of the patah: �֣ ֥ ‫ה־ל‬ ְ ‫ת ֲע ֶ֨שׂ‬.
ֽ ַ If the
relative position of meteg to a vowel is textually important, care
must be taken to prevent reordering through automatic or manual
insertion of the CGJ character, e.g. bet + meteg + CGJ + patah.

3
 Puncta extraordinaria Puncta extraordinaria (extraordinary points) occur fifty-six times in
This section explains the the Old Testament text: fifty-three times above letters and three
current recommendation times below letters. The electronic edition of the Biblia Hebraica
for encoding the puncta Stuttgartensia text notes that the function of these marks
extraordinadia, illustrating is not entirely clear, but it has variously been proposed that: a) the
how they should appear if marks are merely emphasis and draw special attention to the theological
rendered correctly. implications of the word; b) the marks are early critical marks which
indicate an omission or change that the scribes desired to make, but dared
not; c) the marks represent drops of ink or even bits of dirt that were
Biblia Hebraica Stuttgartensia : slavishly copied from one manuscript to the next; d) the marks indicate a
with Westminster Hebrew special or unusual pronunciation of the word, or that the word should not
morphology. 996 (electronic ed). be read at all; or e) some mixture of the above, on a case-by-case basis.

The most complex example of puncta extraordinaria is in Ps 27:3, in

which puncta appear both above and below, and with other marks.
Note that, in accordance with the recommend mark or-

���� ��� dering on page 2, the complex combination of lamed

with above and below marks plus puncta in this example
should be encoded consonant + vowel + puncta below +
The lower punctum was mark above + puncta above. Also note that because the puncta ex-
previously encoded in SBL traordinaria are positioning above and below the level of most other
Hebrew using the generic marks, it may be necessary to increase linespacing in those parts of
combining dot below (U+0323). the text where these marks occur.
Documents produced with this The SBL Hebrew font encodes these marks using the Hebrew ‘up-
earlier encoding will need to be per dot’ (U+05C4) and Hebrew ‘lower dot’ (U+05C5) characters; the
updated. latter is a new character in version 4. of the Unicode Standard.

Atnah hafukh and The new atnah hafukh (U+05A2) character has been included in Uni-
qamats qatan code 4. for the benefit of those users who wish to encode an explicit
This section explains two new distinction between this accent and yerah ben yomo (U+05AA). Many
characters in Unicode 4. and editions do not make this distinction, using the yerah ben yomo char-
their implementation in this acter and its glyph to represent both accents. Since this is a new
version of SBL Hebrew character, with some disunification legacy issues (the form of the
yerah ben yomo character used in many typefaces is actually that of
the atnah hafukh), support in this version of SBL Hebrew is prelimi-
nary and subject to review: the character code is supported, but the
glyph is identical to that used for yerah ben yomo,
The new qamats qatan (U+05C7) character makes it possible, if de-
sired, to encode an explicit distinction between this vowel (short qa-
mats) and the long qamats (U+05B8, qamats gadol). To visualise this
distinction, following a convention adopted in some editions, the
glyph for this new character is noticeably taller than that for qamats
gadol.

4
 Masora/Number dot Not to be confused with the high puncta extraordinaria, this high dot
This section explains the mark is used primarily in the context of Masoretic notes, as in this
use of the upper dot mark example from Num 32:24:
in Masoretic notes and for
Hebrew numerals ¹⁵‫מפק א‬
̇ ̇‫ י̇ ז‬. ¹⁴‫̇ב‬ ‫נוּ־ל ֶכ֤ם ָע ִר ֙ים ְל ַט ְפּ ֶ֔כם וּנְ ֵ ֯ד ֭ר ֹת ְלצֹנַ ֲ֯א ֶכ֑ם‬
ָ ‫ְבּ‬
MASORA TEXT

Like the low puncta extraordinaria the masora/number dot is not en-
coded in the Unicode Standard as a specifically Hebrew character, so
a generic combining dot above (U+0307) is used.
For a complete table of Hebrew The same character is sometimes used to indicate a consonant
numerals, see R. Wonneberger, used as a numeral in the traditional Hebrew numbering system: ‫=א‬, ̇
Understanding BHS, 990.
‫=ב‬2,
̇ ‫=ג‬3
̇ … ‫=י‬0,
̇ ‫=כ‬20,
̇ ‫=ל‬30,
̇ and so on, with nine consecutive letters
of the alphabet used for units, tens and hundreds up to 400 (some
sources identify final letter forms for 500–900).
See, for example, Georges Ifrah, A This numbering system is extended in some reference books
universal history of numbers, 998 to counting in thousands by doubling the dots: ‫=א‬000,̈ ‫=ב‬2000,
̈
(original French edition 994).
‫=ג‬3000,
̈ etc.. The double dot is encoded using the generic combining
diaeresis character (U+0308).

Masora circle handling The circle indicating a Masoretic note can occur over a consonant,
This section explains how between consonants, over a maqaf, or over a word space. Ideally, it
to encode and control the should be centred over a word, but there is no way to specify this
positioning of the masora in Unicode combining mark encoding or OpenType Layout. Manual
circle. care must be taken with the positioning. The SBL Hebrew font, by
default, places the masora circle above the preceding consonant,
maqaf or word space, as on these examples from the first chapter of
Genesis:

ְ ֯ ‫ ֵﬠ‬¹¹ … ‫ ֶאל־֯֯ ָמ ֣ק ֹום‬⁹ … ‫מ ַר ֶ ֖֯ח ֶפת‬²

‫֣ץ�פּ ִ ֞רי‬ ְ
The masora circle glyph is centered on a zero-width, which means
that if the default positioning is inhibited it will automatically be
placed between the character to which it is applied and the next. The
positioning can be inhibited by inserting the ZWNJ control character
between the masora circle and the consonant, maqaf or word space
to which it is applied. In the examples below, also from Genesis ,
the character sequence is consonant + [vowel/cantillation mark(s)] +
ZWNJ + masora circle.

�֯�‫וַ יְ ָ ֣ב ֶר‬²⁸ … ‫בּיַּ ִ֔מּים‬²²

֯� … ‫וּלִ�֯מ ְק ֵו֥ה‬¹⁰
ְ
Note that, as shown in the last example from Genesis :28, the ZWNJ
character can also be used to position a masora circle after a word
break at the end of a line.

5
 Holam male Some texts—both manuscript and typographic—make a visual dis-
This section explains the tinction in the position of the dot between a vav haluma, i.e. vav fol-
encoding of the vowel holam lowed by a holam haser ( ֹ �‫) ו‬, and the independent vowel holam male
male, distinct from vav with ( ‫) וֹ‬. Some texts do not make this distinction, displaying both as ‫וֹ‬,
holam haser. and some electronic documents may even encode both graphemes
the same way, relying on the reader’s expertise to distinguish them.
Earlier versions of the SBL Hebrew font used a mark+base order-
ing convention to distinguish holam male and vav haluma, but this
has been deprecated because the holam male encoding was counter
to basic Unicode rules about base+mark ordering. The correct encod-
ing of this distinction has been the subject of much discussion in
Unicode circles, and the standard is in the middle of a transition to a
robust encoding distinction. The consensus is that the character se-
Documents using the quence vav + holam (U+05B9) is the correct encoding for holam male,
earlier conventions of since this is far more common than the relatively rare vav haluma.
holam + vav = holam male / This is implemented in version . of the SBL Hebrew font:
vav + holam = vav haluma
will need to be updated. ‫ = וֹ‬vav + holam (holam male)
Since such updates are Unfortunately, at the time of writing there is no standard means
complicated, we are no longer to encode a distinct vav haluma. A new combining mark character,
recommending any interim HEBREW POINT HOLAM HASER FOR VAV, has been proposed and is
hacks to encode the distinction, approaching balloting, but is not available yet. If approved and en-
but instead encouraging users coded, this will provide a robust encoding distinction for those users
to patiently await a robust and who wish to differentiate holam male and vav haluma as illustrated in
standard solution. the fourth and fifth words of this example from Genesis 4:3 :

��� �� ���� ����� ��� ���� �� ����

� ������ � ���� � ���
� � �� ��

Nun hafukha Nun hafukha—‘inverted nun’—is not a letter, but a form of special
This section explains a punctuation that occurs only a handful times in the Hebrew Bible
mechanism for displaying the (see Numbers 0:35–36). Hebrew manuscripts show a number of dif-
‘inverted nun’ glyph. ferent forms for this character, depending on the script style, only
one of which corresponds to an inverted nun letter. This character is
encoded in Unicode as the new character U+05C6.

‫ = ׆‬nun hafukha
In pointed texts, the inverted nun carries a dot above it. For this, the
masora/number dot character (U+0307) should be used:

‫̇׆‬ = nun hafukha + masora/number dot

6
Support in non-Windows The term ‘font support’ can refer to a number of different things,
systems & applications from installability to text display to complex glyph rendering, so
This section explains the when wondering whether a particular operating system or applica-
current state of support for tion (or particular combination of OS and application) supports use
SBL Hebrew on Macintosh & of a font it is necessary to understand the limitations that can apply.
Linux operating systems.
Macintosh. The Mac OS X operating system can natively install and
render the SBL Hebrew ‘data-fork’ format Windows TrueType font.
Older versions of the Mac operating system cannot natively install
this format, and need a Mac-specific ‘resource-fork’ format font file.
At present, no resource-fork version of the SBL Hebrew font is avail-
able, since there are so few Unicode enabled applications for older
Mac operating systems. Note that some applications, particularly
new versions of much Adobe software (on both Mac and Windows),
can install fonts, including SBL Hebrew, directly in their own font
folders and use their own rendering technology, bypassing system
font handling; some of these applications may provide support on
older versions of the Mac operating system.
The latest version of OS X, Tiger, implements some system level
support for basic OpenType Layout features, converting them on
the fly to Apple’s own AAT format features. However, this does not
include support for complex script layout, so the all-important mark
attachment is not supported at the system level. This means that
applications relying on standard system calls for text processing will
not be able to handle Biblical Hebrew text using SBL Hebrew, even
though they may support Unicode text encoding and basic right-to-
left layout.
Applications that use their own text layout engines, designed to
work with OpenType fonts, offer the most hope for Macintosh us-
ers. At the time of writing, none of these applications offer the same
high level of Biblical Hebrew rendering as Microsoft Office 2003 on
Windows, but some are gradually getting close.
See Appendix C on page 22 Mellel is a word processing application for OS X that employs
for web link information on OpenType Layout natively using its own text engine. Biblical He-
Mellel and other applications brew test results from Mellel are encouraging, with almost all tested
mentioned in this section, letter+mark sequences rendering correctly. One problem in the cur-
rent release is that there is no way to turn off visual display of con-
trol characters, so if you insert e.g. the Zero Width Joiner character
in a sequence Mellel will display a small mark above the letters. [In
Microsoft Word on Windows, display of control characters is off by
default, but can be turned on to facilitate editing; this behaviour is
preferred.]
XeTeX is a typesetting system that marries Donald Knuth’s TeX
system with Unicode text encoding and OpenType Layout. Only a
7
 small number of users appear to be using this for Biblical Hebrew,
but the examples they have submitted are impressive and indicate
that XeTeX provides some of the best support for Hebrew outside of
the Windows version of Word and other Office applications. XeTeX
makes use of the ICU layout library discussed below.

Linux. As with many other aspects of open source computing, the

level of support for Biblical Hebrew on Linux depends very much
on specific distribution, library and application configurations. This
section of the manual is necessarily short simply because we have
limited experience in this area, and have only recently begun to ex-
plore it.
Users of the SBL Hebrew font who are interested in Hebrew
rendering on Linux systems are encouraged to investigate the ICU
and Pango, two code libraries that provide support for Unicode text
processing including OpenType Layout support. Tests of current
version of Pango, compiled into the Firefox web browser, show cor-
rect positioning of single accent to single vowel combinations, but
errors in second accent and accent-to-accent relative positioning.
Results from applications using ICU seem better.
Linux-based users of the SBL Hebrew font are particularly encour-
aged to join the MSN user community, and to share tips and tricks for
working with Biblical Hebrew text on this platform.

Conclusion As should be clear from this manual, the SBL Hebrew font is on the
‘cutting edge’ of text processing and layout technology, and much
software still needs to catch up to the font in order to perfectly
render all aspects of Biblical Hebrew texts. That said, in the seven-
teen months since the last version of this manual was written, there
have been encouraging advances, especially on the Mac and Linux
systems.
During development of the font, key software developers such as
the Microsoft development lead responsible for the Uniscribe He-
brew engine have consulted on the best way to encode and shape
Biblical Hebrew and have provided beta versions of upcoming soft-
ware releases for testing. This consultation has enabled us to make
a font that outperforms all previous Hebrew text rendering, and
which will enable Biblical scholars to create, edit and exchange docu-
ments between the increasing number of systems and applications
that support Unicode text encoding and OpenType Layout.

8
 Appendix A . The digitally encoded machine readable font software for producing the type-
End User License Agreement faces licensed to you is the property of Tiro Typeworks. It is licensed to you for
use under the terms of this end user license agreement. If you have any ques-
tions about this license agreement, or have a need to use the font software in a
This license agreement explains way not covered by this agreement, please write to [email protected].
the rights and responsibilities
2. You may use this font software free of charge for all non-commercial purposes.
that you accept when you If you wish to obtain a license for commercial use of this font software, please
install the SBL Hebrew font contact the Society of Biblical Literature at [email protected], or write to
on your computer. Please take a [email protected]. Fees for commercial licenses are at the individual discretion of
few minutes to review this. the Society of Biblical Literature and Tiro Typeworks.
3. You may redistribute this font software free of charge as long as the software is
unmodified, all copyright and trademark notices are intact, and the font contains
or is accompanied by a copy of this license agreement. You may not charge any
fee for the distribution of this font software or alter the terms of this license
agreement.
4. You may decompile and modify this font software for non-commercial and
personal use by you as an individual or internal use within your organisation.
Tiro Typeworks maintains copyright to all derivative fonts in any format. You
may not delete, edit or add to copyright, trademark or license information in
the font. You may not change the embedding bit. You may not redistribute any
modified version of the font software, either free of charge or for a fee. Copies of
modified fonts should be submitted to Tiro Typeworks ([email protected]) and to
the Society of Biblical Literature ([email protected]), along with any relevant
documentation. Tiro Typeworks reserves the right to incorporate any such
changes into its own fonts.
5. You may embed the font software in non-commercial electronic documents,
including but not limited to web pages and e-books. Font embedding must re-
spect the embedding bit in the font, which must not be changed. The embedding
bit for this font software is set to ‘Editable Embedding’, meaning that documents
containing this font software may be viewed, printed and edited, but the embed-
ded font may not be installed on the recipient user’s system.
6. All other rights are reserved by Tiro Typeworks, except as otherwise designat-
ed in contract between Tiro Typeworks and the Society of Biblical Literature.
7. Neither Tiro Typeworks not the Society of Biblical Literature warrant the per-
formance or results you may obtain by using this font software. Excepting any
warranty, condition, representation or term that cannot or may not be excluded
or limited by law applicable to you in your jurisdiction, Tiro Typeworks and the
Society of Biblical Literature make no warranties, conditions, representations,
or terms (express or implied whether by statute, common law, custom, usage or
otherwise) as to any matter including, without limitation, noninfringement of
third party rights, merchantability, integration, satisfactory quality, or fitness for
any particular purpose.
8. Neither Tiro Typeworks nor the Society of Biblical Literature accept any li-
ability for injury, death, financial loss or damage to person or property (includ-
ing computer hardware, software or data) resulting from the use of this font
software.
9. The act of installing this font software on any computer system constitutes
acceptance of the terms of this license agreement, without exception.

9
 Appendix B See the discussion on pages 8– for more information about nor-
Custom combining classes. malisation issues, and the Unicode Standard for details of standard
n0rmalisation and combining classes. Below are suggested canoni-
As explained on pages 8–, cal combining classes to use in custom normalisation routines for
Unicode normalisation may Biblical Hebrew text. As in standard normalisation, the expectation
break Biblical Hebrew text is that only marks in different combining classes will be reordered
by reordering marks that during normalisation; marks with the same combining class value
should not be reordered. This should not be reordered. The lower the combining class value, the
appendix provides alternate closer to the base character (e.g. Hebrew consonant) the mark should
combining classes to use be ordered. In this table, the recommended combining class is pro-
in custom normalisation vided first, then the existing Unicode combining class in grey, and
routines. Nota bene: these then the Unicode codepoint and a descriptive name.
alternate combining classes
10 24 U+05C1 Point Shin Dot
are outside of any recognised
11 25 U+05C2 Point Sin Dot
standard, and text produced
21 21 U+05BC Point Dagesh or Mapiq
using custom normalisations
23 23 U+05BF Point Rafe
may still be subject to other
27 19 U+05B9 Point Holam
normalisations in software
220 220 U+05C5 Lower Punctum
beyond the author’s control
220 220 U+0591 Accent Atnah
(e.g. web browsers). This list is
220 220 U+05A2 Accent Atnah Hafukh
provided purely as a suggestion,
and no guarantee is made 220 220 U+0596 Accent Tipeha
that it will be supported as is 220 220 U+059B Accent Tevir
in software developed by SBL, 220 220 U+05A3 Accent Munah
Tiro Typeworks, or any of their 220 220 U+05A4 Accent Mahapakh
project partners. 220 220 U+05A5 Accent Merkha
220 220 U+05A6 Accent Merkha Kefula
220 220 U+05A7 Accent Darga
220 220 U+05AA Accent Yerah Ben Yomo
220 10 U+05B0 Point Sheva
220 11 U+05B1 Point Hataf Segol
220 12 U+05B2 Point Hataf Patah
220 13 U+05B3 Point Hataf Qamats
220 14 U+05B4 Point Hiriq
220 15 U+05B5 Point Tsere
220 16 U+05B6 Point Segol
220 17 U+05B7 Point Patah
220 18 U+05B8 Point Qamats
220 18 U+05C7 Point Qamats Qatan
220 20 U+05BB Point Qubuts
220 22 U+05BD Point Meteg
222 222 U+059A Accent Yetiv
222 222 U+05AD Accent Dehi

20
 230 230 U+05C4 Upper Punctum
230 230 U+0593 Accent Shalshelet
230 230 U+0594 Accent Zaqef Qatan
230 230 U+0595 Accent Zaqef Gadol
230 230 U+0597 Accent Revia
230 230 U+0598 Accent Zarqa
230 230 U+059F Accent Qarney Para
230 230 U+059E Accent Gershayim
230 230 U+059D Accent Geresh Muqdam
230 230 U+059C Accent Geresh
230 230 U+0592 Accent Segolta
230 230 U+05A0 Accent Telisha Gedola
230 230 U+05AC Accent Iluy
230 230 U+05A8 Accent Qadma
230 230 U+05AB Accent Ole
230 230 U+05AF Mark Masora Circle
230 230 U+05A1 Accent Pazer
230 230 U+0307 Mark Number/Masora Dot
232 228 U+05AE Accent Zinor
232 230 U+05A9 Accent Telisha Qetana
232 230 U+0599 Accent Pashta

The makers of the SBL Hebrew font would like to thank the individuals and or-
ganisations who participated in ad hoc discussions to determine an appropriate
mark ordering for normalised Biblical Hebrew, especially Peter Constable (SIL
International) and Eli Evans (Libronix/Logos). Other contributors included Joan
Wardell (SIL International), Patrick Durusau (SBL), Ralph Hancock, Paul Nelson
(Microsoft), Bob Pritchett (Libronix/Logos), & Kent Richards (SBL).

2
 Appendix C http://www.sbl-site.org/Resources/default.aspx
Resource links The latest version of the SBL Hebrew font, this manual, the conso-
nant + mark(s) test document, and other information relating spe-
This appendix provides URLs for cifically to SBL Hebrew; downloadable Windows keyboard drivers
font and document downloads for input of Biblical Hebrew text.
and online resources from the
http://www.sbl-site.org/
Society of Biblical Literature
Society of Biblical Literature website.
and other parties.
http://www.tiro.com/resources/hebrew
Tiro Typeworks resources for Biblical Hebrew, including normalisa-
tion example documents.

http://www.unicode.org/
The Unicode Consortium website. Includes latest version of
Unicode Standard and resources.

http://www.microsoft.com/typography/specs/default.htm
OpenType specification and Microsoft Hebrew font specification.
http://www.microsoft.com/typography/developers/
opentype/default.htm
‘Windows Glyph Processing’ article by John Hudson; an introduc-
tion to OpenType font and Unicode script processing on Windows.

http://www.redlers.com/mellel.html
Mellel is a powerful multilingual word processor for Mac OS X. It’s
handling for Biblical Hebrew is not yet perfect, but it is very good.
http://scripts.sil.org/cms/scripts/
page.php?site_id=nrsi&item_id=xetex
Download site for the open source XeTeX page layout application
for Mac OS X.
http://www.winsoft.fr/
Winsoft make the Middle East versions of Adobe software, includ-
ing InDesign ME, which was used to typeset this manual.

http://www-306.ibm.com/software/globalization/
icu/index.jsp
International Components for Unicode: an open source set of
libraries for Unicode support, software internationalization and
globalization. Provides excellent OpenType Layout support.
http://www.pango.org/
An open-source framework for Unicode text layout and rendering.

22