Re: Automatic paragraph direction in gtktextlayout



dov imagic weizmann ac il writes:

> Each paragraph should be decided independently whether it is RTL
> or LTR. Only if there are no strong characters in the paragraph 
> (E.g. a single line containing the "> " string), will the direction
> be according to the the previous paragraph. Of course the user 
> can modify the direction by insertion of a RLM or LRM zero-width
> unicode control character. 
> 
> About switching the direction according to the keyboard map, I
> don't think it is possible. As far as I understand the text widget
> has no information of the keyboard layout at all, and only responds
> to characters that are input. As switching the keyboard layout is
> done internally inside server, I don't think it generates
> any event that may be caught and identified by the widgets. Also, as 
> far as I understand, it is not possible to have the widgets request a 
> change in keyboard layout that might be desirable by clicking on
> a strong LTR or RTL character. I am not sure about this though,
> as I'm not an expert on gdk, and would be happy to be proven wrong.

Have you tried putting 

 gtk-split-cursor = 0

In your ~/.gtkrc-2.0? GTK+ (when XKB is available) can and 
does detect keyboard layout changes. (The only problem
is it has to reverse engineer the directionality of the
keyboard layout from the name of the keyboard group.

I'm not sure how this would relate to strong directionality
though  ... I guess the GtkTextView could automatically
insert a LRM if the keyboard was in left to right mode
and you began a new paragraph with a neutral or storng
RTL character.

As for modifying GtkTextView as suggested, it's pretty darn
hard, and I'm not really convinced that the result would
be what you want. Some issues:

 * If you have the "same as last paragraph rule", cut
   and paste of entire paragraphs might change their
   strong directionality.

 * In any case, "same as last paragraph" is virtually impossible
   to implement, since the text view depends on each
   paragraph being independent. (And "same as last paragraph
   would mean that a change to the first paragraph of 
   text could change something 1000 lines farther down.)

 * I think the guessing could be very confusing to the
   average user when it got it wrong and the correction
   (inserting a LRM or RLM at the beginning of the paragraph)
   is not at all obvious. A good reason to keep implementation
   simple is so that the mental model that users have
   to deal with is simple. Sometimes clumsy is better
   than clever.

There are several interrelated questions here:

 * Display of an external document. Here consistency
   with standard rules is very important for correct
   display. If people are using auto-guess algorithms
   for strong directionality, then you want to to,
   or want to do a preprocessing step to add explicit
   directionality before inserting into the text
   widget.

 * Editing a document that will be saved as plain text.
   Here, the user has to be guided to inserting the
   "right" Unicode formatting characters.
 
 * Editing a document that will be saved as rich text.
   It's easier in this case to have a menu item 
   "Paragraph RTL" that slaps directionality tag over
   the paragraph setting the strong direction for that
   paragraph.

I don't have a good answer here, and a good answer would
depend on:

 a) Analysis of what existing documents assume for processing
 b) User testing

b) clearly would also involving fleshing out how 
inserting directional marks and other bidi editing operations
should work in GtkTextView.

What I would say at this point is:

 * I think "same as last paragraph" is a bad idea, 
   as well as being unimplementable. Luckily paragraphs
   without any directional characters are rare.
   In such cases, you should just fall back to
   LTR (as suggested by the Unicode algorithm) or 
   to the GTK+ global default direction.

 * I'm not sure if auto-guessing is a good idea or
   not. The Unicode standard does say that you should
   do it when the directionality is _not_ specified
   by a "higher level protocol". It's not clear
   to me what a higher level protocol is in this
   context exactly.

   Since the Text widget certainly _can_ be used to
   display things where directionality is carried
   in markup, you'd at  most want to autoguess
   direction if no "direction" attribute applied
   to the current paragraph.

Regards,
                                        Owen





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