Why do the Hebrew Alphabetic Presentation Forms Exist

[Richard Wordingham]

On Thu, 4 Jun 2020 17:08:57 -0400
"Mark E. Shoulson via Unicode" <unicode at unicode.org> wrote:

> 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.

Well, there's the rub.  One loses layout control between italicised and
unitalicised  portions.  This is how one would apply them using CSS.
Of course, the system might be clever enough to work round breaks.  The
wording of the salt feature at
https://docs.microsoft.com/en-us/typography/opentype/spec/features_pt#-tag-salt
suggests that the conception was that the salt feature would enable
substitutions of a single glyph by another glyph, with a user interface
allowing the user to choose the replacement glyph from a menu.  There's
no whiff of the notion that the choice presented might be context
dependent.  A clever enough system could have context-sensitive
substitutions before and after that straddle the change in options
selected.  Other systems might not allow interactions between spans
with different options chosen.

Richard.





  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.)
> 
> ~mark
> 
>