Christian Palestinian Aramaic

Roozbeh Pournader roozbeh at
Thu Oct 9 11:24:50 CDT 2014

Two things:

1. You should be able to get the behavior you want through 'calt' or 'dlig'
OpenType features. You'd need to add more lookups to your font than a
typical Syriac font, but that's to be expected, considering that you are
working with slightly atypical material.

2. Based on the exact situation, we can encode more characters in the
Syriac block or change the properties of existing characters. It'd be great
if you could write a document for the UTC with samples and explanation, so
we can figure it out at the next meeting.
On Oct 9, 2014 7:33 AM, "P.D. Myers" <pdm42 at> wrote:

> Hello all,
> The Unicode manual, p. 384 (
> versions/Unicode7.0.0/ch09.pdf) states:
> "Christian Palestinian Aramaic. Manuscripts of this dialect employ a
> script that
> is akin to Estrangela. It can be considered a subcategory of Estrangela."
> However, I am working on a CPA font developed for a team who have been
> transcribing a CPA palimpsest which has several more joining characters
> than are found in Syriac scripts.
> Examples: in the palimpsest both waw (ܘ) and hey (ܗ) are double joining
> characters, whereas in Serto these letters are only right joining.
> 1. Is it possible, using OpenType tables in FontLab 5, to produce a font
> that renders this behaviour on desktop software? When I script the tables
> as standard Syriac features, then these letters do not join in word
> processing software (Word, Pages, or Mellel). However, if I script the
> tables without using the preset Syriac features, I can get all letters to
> join together, but then some mission-critical functions in word processing
> software are not available (for example, the zero-width-joining character
> does not force a joining ligature—this is needed to force joining
> characters next to punctuation marks used for text-critical purposes). The
> documentation for FL5 has led me to the conclusion that this is an
> insurmountable problem, as the join-behaviour is fixed by the Unicode
> standard (in other words, I can't treat a Unicode character as double
> joining, unless it is defined as double joining by the standard). Am I
> correct in this conclusion?
> 2. Is there a case to be made here for CPA to be given its own unicode
> block?
> Kind regards,
> Pete Myers
> --
> Rev Peter D. Myers
> PhD Candidate Cambridge University, Hebrew transcription in Greek script
> Faculty of Asian and Middle Eastern Studies, Wolfson College
> pdm42 at
> 07930 22 22 17
> _______________________________________________
> Unicode mailing list
> Unicode at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Unicode mailing list