emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Line wrap reconsidered


From: Yuan Fu
Subject: Re: Line wrap reconsidered
Date: Fri, 19 Jun 2020 13:22:18 -0400


> On Jun 19, 2020, at 8:38 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Fri, 19 Jun 2020 08:04:47 -0400
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>,
>> emacs-devel@gnu.org
>> 
>>> Maybe I don't understand the exact meaning of NOT_AT_EOL/NOT_AT_BOL
>>> that Kinsoku assigns to that.  Can you provide a formal definition of
>>> that, or point me to some document where that is explained?  
>> 
>> Since kinsoku.el is for asian characters which are all LTR[1], the exact 
>> meaning of NOT_AT_EOL/NOT_AT_BOL in bidi context probably doesn’t really 
>> matter, but to make kinsoku retain the same behavior (thus looks right) in 
>> both RTL and LTR lines, I choose to define BOL as left edge and EOL as right 
>> edge. So NOT_AT_EOL means can’t be the right-most character in a line.
>> 
>> From your message I thought in RTL lines the iterator draws from right to 
>> left (you said each glyph is prepended to the previous one). So in RTL 
>> context when we are at the end of a logical line, we are at the left edge; 
>> on the other hand, in normal LTR context when we are at the end of a logical 
>> line, we are at the right edge. Hence the flip.
> 
> What do you mean by "in the RTL context"?
> 
> Remember: bidi reordering can take place in two different situations:
> then the paragraph direction is left-to-right, and when it's
> right-to-left.  In the former situation, the lines begin on the left,
> in the latter they begin on the right.  But LTR text, such as CJK
> characters, will always be rendered left-to-right, no matter what is
> the paragraph direction.
> 
> So which "RTL context" did you mean here?

Oooh so there are four cases: LRT text in LTR paragraph, LRT text in RTL 
paragraph, RTL text in RTL paragraph, and RTL text in LTR paragraph. And the 
order in which the iterator draws glyphs depends on the paragraph order 
(although it doesn’t know it). Am I right?

> 
>> As I mentioned above, I don’t think kinsoku cares/is defined for this 
>> situation. And I took the definition to assume strict LTR, mapping BOL to 
>> left and EOL to right. The ultimate effect is that, no matter what the bidi 
>> context is, NOT_AT_EOL character, like 《, never appears at the right edge. 
>> So we don’t get
>> 
>> 
>> 我今天看来了本书,感觉挺有意思,名字是《
>> 钢铁是怎样炼成的》。
>> 
>> Instead, we have
>> 
>> 我今天看来了本书,感觉挺有意思,名字是
>> 《钢铁是怎样炼成的》。
> 
> What do you see in the text below?
> 
> אבגד הוזחטיכך למנן 我今天看来了本书,感觉挺有意思,名字是
> 《钢铁是怎样炼成的》。
> 
> (I assume you are reading your email in Emacs; if not, copy/paste this
> text into an Emacs buffer whose bidi-paragraph-direction is nil, and
> look at the resulting display.)
> 
> Does the above look correct, from the Kinsoku POV?  This is how LTR
> CJK text will be displayed in a paragraph with right-to-left base
> direction.  Do you still think something needs to be flipped here?

Kinsoku looks right, yes. However the period (“。”) seems to be interpreted as 
RTL text, not sure why.

> 
>> Now, is that mapping TRT for other characters? I don’t know. But I think it 
>> make sense for kinsoku (again, asian text, all LRT). IMHO, maybe for a 
>> generic definition we can define BOL as left edge for LTR character and 
>> right edge for RTL character. I think that will look good for most text.
> 
> We must use BOL and EOL in their logical-order meanings, otherwise the
> result will be utter confusion.  In the above example, the EOL
> character in the first line is 是, and it is not at the left edge of
> the line.  It is at the logical-order end of the line, i.e. the
> character after it in the buffer position order is the newline.  But
> if we had RTL characters instead of the CJK text above, the character
> at EOL would indeed have been displayed at the left edge of the line.
> 

I see. However, I suggest to define EOL and BOL (in kinsoku) in terms of visual 
edges, instead of the logical order. Because we are using this information 
(NOT_AT_BOL, etc) for visual layout. When we are at a window edge and ask if 
this character can appear at this edge, we are interested in the visual aspect 
rather than the logical order, if you get what I mean. 

BTW, what does it->bidi_p mean exactly? Does it mean bidi-display-reordering is 
t, or current paragraph is ‘right-to-left, or the char at point is RTL, or 
something else? (I think I used it wrong in the patch) Can I know whether I’m 
at the left edge or the right edge?

Thanks for patiently educating me on this, I’m making slow progress :-)

Yuan


reply via email to

[Prev in Thread] Current Thread [Next in Thread]