As you are probably aware, Hebrew has cantillation/trope marks, which are used to indicate the melody used when reading Torah in a religious context.
There is a growing community which uses the trope marks for English text; see an example on page 5 of this PDF, or at this category page of opensiddur. However, when used for English, the trope marks are generally handwritten, or replicated with vector symbols, because they need to be horizontally flipped (to match the script direction) and attach properly to the corresponding letters.
I’m aware of one existing font that supports trope mark glyphs for English text, but it does so using the old pre-Unicode approach of mapping the glyphs into Latin codespace. I wanted to do something better.
So I created a fork of Tinos (an OFL-licensed font which is metrically compatible with Times New Roman), renamed it “Tropos”, and started experimenting.
The trope marks are coded in Unicode from U+0591 to U+05AE. I created mirrored
glyphs of these codepoints and wrote a ltrm
feature to swap out the RTL-direction glyphs for the LTR-direction
glyphs when used in a LTR context. I also added codepoints in the Private Use
Area for the mirrored trope mark glyphs, because I suspected some
applications wouldn’t do what I wanted with the normal codepoints.
Then I defined a mark
feature to position the mirrored trope glyphs against Latin characters
(specifically the English alphabet, as a starting point, plus U+25CC as
a placeholder). The
mark-to-base feature’s lookup table contains rules for positioning both
the mirrored glyphs produced by the ltrm feature, as well
as the mirrored glyphs coded in the Private Use Area.
You can find the UFO sources (including feature.fea
files) in branch
ltrm of this repository. I have also provided the built TTF files in a
zipfile for convenient
download.
I created a sample document derived from page 5 of the Kessler PDF, containing a few paragraphs of English text with trope marks, using both the original Hebrew codepoints as well as the PUA codepoints.
I also used the hb-view
utility from HarfBuzz to generate some reference images.
ltrm enabled but mark disabled
mark
enabled (correct rendering)
mark
disabledHarfBuzz produces identical-looking output when the mark
feature is enabled, no matter whether Hebrew or PUA codepoints were
used. We can also see that when the mark feature is
disabled, the trope mark glyphs appear offset from where they should be.
And when the ltrm feature is disabled, rendering uses the
original RTL glyphs and of course nothing looks correct at all.
For example, the mark shaped like a greater-than sign
(>) should appear directly under the u in burning or the
e in beating, but when mark is disabled, it appears between
those letters and their following letters.
These results were obtained by viewing the HTML sample text and printing to PDF in each browser, on my MacBook running Mac OS 15.3.2, except that Edge was running on my Windows 11 PC.
This is Firefox 136.0.1. Both the Hebrew and PUA codepoints render correctly.
This is Chrome 134.0.6998.89. The Hebrew
codepoints render correctly, but the PUA codepoints do not; it looks
like the mark feature is not being used for positioning the
PUA mark characters against the Latin base characters.
This is Safari 18.3.1. Here, the PUA
codepoints render correctly, but the Hebrew codepoints do not; again, it
looks like the mark feature is not being used for
positioning the Hebrew mark characters against the Latin base
characters.
This is whatever version of Edge was installed on the Windows 11 PC; I don’t normally use Edge. Much like Chrome (on which it is based), it renders the Hebrew codepoints correctly, but not the PUA codepoints.
I converted the sample document to LaTeX. It uses fontspec, which requires either XeLaTeX or LuaLaTeX.
XeLaTeX produces correct rendering.
In LuaLaTeX, correct rendering
requires enabling the HarfBuzz renderer; otherwise the ltrm feature
will not be
used.
I tested the sample document in Apple’s TextEdit.app, Apple’s Pages, LibreOffice (on both Mac and Windows), and Microsoft Word.
In both these apps (TextEdit) (Pages), the ltrm
feature correctly
substituted the mirrored glyphs, but the mark feature is
not being used to correctly position the Hebrew mark characters.
However, the PUA mark characters are correctly positioned.
I had LibreOffice 24.8.3.2 installed on my Mac and 24.2.2.2 installed
on my Windows PC. In both versions, the ltrm feature does
mirror the glyphs, but the mark feature does not correctly
position the glyphs for either set of codepoints.
Disappointing, especially since I’d heard that LibreOffice uses HarfBuzz
for text shaping; I suppose it must be segmenting the glyphs into
different runs before passing them to HarfBuzz.
Word was the worst offender. It does not use the ltrm
feature to mirror the glyphs when using the Hebrew codepoints, and it
also does not use the mark feature to correctly position
the PUA codepoints.
Moreover, Word’s built-in PDF export apparently omits the PUA glyphs entirely. I had to use the Windows print-to-PDF feature to get the PUA glyphs to display at all.