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
More information about the Unicode