Re: בעיות עברית בגנום

[Dov Grobgeld]

A few comments.

1. The unicode algo actually does not specify how the paragraph direction is
specified. Instead it delegates the decision to a "higher level protocol".
It was therefore necessary to create a strategy for defining how the
GtkTextView should determine. In the end I wrote a complex routine that
sweeps both backwards and if necessary forwards.

2. Even if it is possible by some higher order routine to insert the
necessary pagraph direction overrides that Amit mentions, it is still
necessary to decide what to do when there is text only. That is all the
current algorithm is doing.

3. The automatic routine can not work in certain cases. E.g. (consider
capital characters to be RTL):

1. c++ IS A LANGUAGE.
2. <h1>SHALOM</h1>
3. moshe: HOW ARE YOU
4. MOSHE: how are you

In the first example "c++" must be skipped to determine the base direction.
One idea I had would be to embed c++ in "neutral override" to show that it
is not to be used for automatic paragraph direction determination.

The same is true for the rest of the example, but it may be done more
automatic. If the source editor would embed "<h1>" in neutral override and
the IM client would embed the "moshe:" and "MOSHE:" via the same protection,
then it would be rendered directly.

4. It would be great if there would be a common BiDi interaction document
that would describe the interaction with regards to issues that are not
handled by the Unicode algorithm. Things like cursor motion, split cursor,
right clip override characters.

Regards,
Dov

2009/1/18 Amit Aronovitch <aronovitch at gmail.com>

>
> 2008/12/10 Diego Iastrubni <elcuco at kde.org>
>
>> חסר מלא באגים ברשימה הזאת:
>> * אין לך יכולת לקבוע כיווניות של שדה קלט, אלא בעזרת תווי בקרה של יוניקוד,
>> אנשים רוצים להשתמש ב־control+shift
>>
>
> הסתכלתי קצת ב- GtkTextView (במחשבה לארגן איזשהו פאטש) - אשמח לעזרה/הערות
> על הערכת המצב ובחירה בין האופציות ליישום המוצעות להלן.
>
> עושה רושם שהמצב הוא כך:
> ( להבנת ההרכב הבסיסי של הוידג'ט הזה:
> http://library.gnome.org/devel/gtk/stable/TextWidget.html   (
>
> 1. כל "שורה" (מה שבד"כ אנו מכנים פסקה) מכילה PangoLayout משלה.
> 2. הכוון הבסיסי שלו (base direction) נקבע אוטומטית עפ"י אלגוריתם יוניקוד
> (במקרה הקצה, כאשר יש רק תוים נייטרליים, עפ"י שורה קודמת, השורה הבאה או מצב
> המקלדת, בסדר זה).
> 3. אפשר להגדיר tags שמגדירים מאפיינים שתקפים לאזור מסוים בתוך הטקסט. אחת
> התכונות שאפשר להגדיר כך היא direction.
> 4. עושה רושם שתכונת ה- direction לא משפיעה כלל על בחירת הכוון. יכול להיות
> שאני מפספס משהו, ואולי וידג'טים אחרים/בנים (למשל SourceView) הם אלה שמשתמשים
> בזה.
>
> עכשיו, יש כמה אפשרויות - וצריך להחליט באיזה כוון ללכת. דעתכם בבקשה (גם לגבי
> נכונות הניתוח הזה):
>
> 1. שליטה גלובלית בלבד על הכווניות: בחירה (אינטראקטיבית/קיצור מקשים וכו')
> בין שלושה מצבים
>      (א) אוטומטי - כמו היום (ב) כל הפסקאות בכוון ראשי LTR (ג) כל הפסקאות
> RTL.
>     זו לא אפשרות גמישה במיוחד, אבל מספיק טובה לשדות קלט קצרים, וכנראה הכי
> קלה ליישום.
>
> 2. כווניות הפסקה תקבע ע"י ה- tags (עפ"י תכונת ה- direction שכבר קיימת).
> הבעיה עם זה היא ש- tags תקפים בגבולות של תוים ולא של שורות. אם נשבור פסקת
> ימין-שמאל לשתיים (ע"י enter ) זה יעבוד (שתיהן יהיו ימין-שמאל, וגם טקסט חדש
> שנכניס באמצע). אבל - טקסט חדש שנוסיף בתחילת הפסקה יהיה כנראה מחוץ לתחום
> הפעולה של ה- tag, ואם "נשבור" אותו, הפסקה החדשה שתווצר תחזור לכווניות
> האוטומטית (כנראה שצריך משהו שמרחיב אוטומטית את גבולות ה- tag, ולא בטוח שזה
> פשוט/יעיל ליישום).
>
> 3. להוסיף ל- TextBuffer שדה של כווניות לכל שורה (היתרון הוא שזה יהיה מוגדר
> פר-שורה ולא בתחום תווים כלשהו).
>
> אני נוטה לכוון 2. מכיוון שנראה לי שזה היעוד המקורי של תכונת ה- direction
> הקיימת (ואולי יש משהו דומה בוידג'טים אחרים). אם כבר משקיעים בכניסה לסורסים
> האלה, אז כדאי ללכת בכוון שש לו יותר סיכוי להתקבל במעלה הזרם...
>
>    עמית
>
> _______________________________________________
> Heb-bugzap mailing list
> Heb-bugzap at projects.hamakor.org.il
> http://hamakor.org.il/cgi-bin/mailman/listinfo/heb-bugzap
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://hamakor.org.il/pipermail/heb-bugzap/attachments/20090118/da63373c/attachment-0001.htm