Why do the Hebrew Alphabetic Presentation Forms Exist

Mark E. Shoulson mark at kli.org
Thu Jun 4 16:08:57 CDT 2020

On 6/4/20 12:27 PM, Richard Wordingham via Unicode wrote:
> On Thu, 4 Jun 2020 09:02:40 -0400
> "Mark E. Shoulson via Unicode" <unicode at unicode.org> wrote:
>>> Arguably, the right place for standardisation is probably OpenType
>>> and AAT features - and it might even be addressed already.
>> Yes, exactly.  An author (or typesetting program, higher level than a
>> font) would have to choose the right variant for each LAMED... which
>> is what 'salt' tables are for, isn't it?
> I was thinking more along the lines of something like tnum, which gets
> digits to have the same advance width so that numbers in rows of
> digits can more easily align. You then don't have to refer to the font
> documentation; if you want that behaviour, either the font doesn't
> support it, or you just specify that feature tnum be applied.
And this, as you mentioned before, affecting the entire document, or at 
least a whole paragraph or table.  But of course, the intent isn't to 
make the user choose between all straight LAMEDs and all bent ones, but 
to allow some to be one and some the other.  I was thinking 'salt' 
tables could be used kind of like formatting instructions, to apply to 
_this_ span and not _that_ one, like you can highlight a single letter 
and italicize it.  Even if they can't be used that way, then maybe it 
isn't a font thing, maybe the the higher typesetting system has to make 
these decisions.  After all, it's something that depends on the entire 
text-block and how the typesetter saw fit to lay it out.  It's like 
hyphenation in that way, if you think about it.  A hyphen character 
can't "know" that it is in a situation where it must break the line and 
become visible; that decision is made by the word processor.  (just 
turning visible at the end of a line can, of course, be handled at the 
font level.)


More information about the Unicode mailing list