Jony took the words right out of my mouth:
> How about RLM?
>
> Jony
This already belongs, naturally, in the context of the Hebrew
text handling, which is going to have to handle bidi controls.
Another possibility to consider is U+2060 WORD JOINER, the
version of the zero width non-breaking space unfreighted with
the BOM confusion of U+FEFF.
WJ is also (gc=Cf, cc=0), so would block canonical reordering
of a sequence it was inserted into. Unlike ZWJ, it should have no
potentially conflicting semantics regarding ligation or anything
else for display. It is *defined* only as specifying no break
opportunity at its position:
"...inserting a word joiner between two characters has no
effect on their ligating and cursive joining behavior. The
word joiner should be ignored in contexts other than word
or line breaking."
Well, as before, we already know that <lamed, patah, hiriq>
^
is not a word or line break opportunity, so inserting a WJ
there should have no effect. And by definition, it should also
have no effect on any glyph ligation (or any other aspect of
the display). But it *would* break up the sequence that
gets canonically reordered for normalization, thus enabling
a textual distinction to be preserved.
One might even want to suggest that if RichEdit or some other
text control causes a display problem when WJ is inserted between
two Hebrew points, that should be considered a bug in the
implementation of the WORD JOINER for that text control.
Of course, I'm not privy to the internals of such implementations
and don't understand the font lookup issues in the kind of
detail that John clearly does, but if WORD JOINER cannot
be implemented as the standard says it should be, then we've
got a more serious problem on our hand than just the
Biblical Hebrew vocalization issue.
--Ken
> >
> > At 04:26 AM 6/26/2003, Jony Rosenne wrote:
> >
> > >I don't think we need any new characters, ZERO WIDTH SPACE
> > would do and
> > >it requires no new semantics.
> >
> > ZERO WIDTH SPACE would screw up search and sort algorithms, I think,
> > because it is not a control character per se and may not be
> > ignored as desired.
> >
> > I've made some tests using Ken's ZWJ suggestion and, as
> > feared, it messes
> > with the glyph positioning lookups. The results varied
> > slightly between MS
> > RichText clients and InDesign ME, but both displayed marks
> > incorrectly when
> > ZWJ was inserted. I strongly suspect that this is not
> > something that can
> > easily be resolved in the glyph shaping model.
> >
> > John Hudson
