Re: Bidi in JSON notes

In that case, why not do definition at the level of the Unicode bidi
algorithm itself? That way any UTF8 stream could carry with it the
necessary meta data. I still fail to see what this has to do with the
serialization format JSON.

So again, what exactly is missing that cannot be expressed by UAX9? The
ability to explicitly set the paragraph direction? If so, perhaps
characters RLP, LRP, and FSP (current default) should be introduced. Of
course their influence on the rendering will be no different than by
placing a RLM and and LRM in the begging of the pargraph, but they may be
treated differently e.g. if doing cut and paste from the middle of a
paragraph with an explicitly set direction.

Regards,
Dov

On Tue, Aug 16, 2016 at 3:19 PM, Matitiahu Allouche <
matitiahu.allouche@gmail.com> wrote:

> Yes, it makes sense, with the help of your explanations. Since I did not
> understand it at first reading, and I may not be the only one, I suggest
> adding a few words to clarify your intent.
>
>
> Shalom (Regards),  Mati
>
> -----Original Message-----
> From: r12a [mailto:ishida@w3.org]
> Sent: Tuesday, August 16, 2016 1:00 PM
> To: Matitiahu Allouche; public-i18n-bidi@w3.org
> Subject: Re: Bidi in JSON notes
>
> On 15/08/2016 20:17, r12a wrote:
> >> 2) You wrote: "Indications of direction change inline would just be
> >> carried over from whatever the original author used."
> >> I don't understand what you mean.
> >
> > I meant that if a user has created some text with multiple
> > lines/paragraphs that requires a mix of base directions, they will
> > probably have to do something during input to the paragraphs after the
> > first one to make the base direction change. Take for example, a
> > textarea in html with several lines of text - either the user will
> > have to rely on getting the righth first strong characters in place
> > for paragraphs after the first if they want the base direction to
> > change in lines/paras 2 and beyond.  That information will be captured
> > with the string.  It's only the first para that relies on the
> > direction setting of the textarea.  (I know that sometimes the user
> > may not be able to get what they want during input, but scripts can't
> > make assumptions about whether the user did or didn't know how to do
> > what they wanted.)
>
> Ah, actually, in that location the line didn't mean what i just explained
> about multiple paragraphs (i missed the 'inline' word).  But the idea is
> the same - given a single paragraph that has some inline changes in base
> direction, those changes need to be signalled by markup or control
> characters in the input itself.  They can't be applied automatically by an
> algorithm, and they can't be carried separately from the payload without a
> significant amount of complexity that i can't see ever working.
>
> Basically, what i'm saying is that if someone types in a string and wants
> it to have an embedded change in base direction, they need to make that
> happen, and whatever they did will become part of the string that is
> carried through, be it markup or controls.
>
> make sense?
>
> ri
>
>
>