Community
Participate
Working Groups
See PR 1GJN5QD: SWT:WIN2000 - bidi - Java Editor - Bad display of several successive literal strings or comments containing Arabic or Hebrew letters We have given thought to solving the bidi code editor problem. Because we need to support LtoR and RtoL markers (i.e., if the user specifically enters them), having ZRH add and then remove the markers is not a good solution due to the fact that in that instance we would want to treat them transparently, whereas in other instances we would not. We are thinking about creating another listener which will callback when a line is to be displayed and ask the application for the line's bidi text segments. ZRH would have to change their code to support this, but it should not be difficult for them to do so. The color-based solution is not the correct solution. It will not work if colors are not used or if certain syntactic segments have the same color. It is also inefficient. Currently the bidi coloring solution is calling GetCharacterPlacement much more than needed and is doing unnecessary processing. NOTES: SN (10/4/01 11:06:05 AM) I think a new callback is fine. They can just give you the coloring ranges as a first cut. The obvious problem is that to do better, they will need to analyze the text and attempt to remember which segments are bidi and which are not. This seems like a lot of hard work. When code is commented, does the text become bidi or does it stay the same? It should stay the same but in order to do this, they would need to parse comments to see if it looks like code? Also they would need to save more information in the file than just the characters so they could recreate the bidi segments. Tons of work. Probably the only way to do this reasonably is with the bidi marker characters but these cause other problems when the file is loaded on a non-bidi local. If they need to use the marker characters, then they won't need your new API. It goes on and on. LK (10/4/01 11:07:21 AM) Since markers can't be saved with the code, that approach won't work since the StyledText is not just being used for the java code editor (i.e., we need to support markers in general which means you can cursor to them, delete them, etc.) As for figuring out bidi text, the ONLY segments they need to worry about are string literals. They already know what a string literal is since they are coloring it. KR (08/10/01 16:31:19) The bidi segment information would not be saved to file. It's purely runtime work. It would work like the line style callback which is called for each line and returns the data for that line. KR (10/8/01 5:14:38 PM) There are a few options on how to spec the data the listener needs to return. 1) Describe the entire line in the returned segments. E.g., if two characters starting at offset five need to be processed separately and the line has six characters. Two segments would be returned. One for the two characters and one for the rest of the line. 1a) Describe the segments using start offset and length. This would be consistent with other StyledText API. 1b) Use the start offset only since the segments are contiguous anyway. 2) Only return the segments that should be calculated/rendered separately, using start offset and length. I.e., only the string literals. KR (09/10/01 12:37:04) Tried out option 1a and ran benchmarks with the JavaViewer with a file containing 500 lines of the following (? is R2L text). public String s = "???" + "???" + "???"; public String s = "???" - "???" - "???"; Measuring is not faster compared to using the StyleRanges (setBidiColoring API), probably because using the StyleRanges only adds one more segment per line (the keyword public). Performance depends on how the StyleRanges are used. If, like in Eclipse, even unstyled/default colored text has a StyleRange the new approach would likely be faster because it would do a lot fewer calls to GetCharacterPlacement. Computing the actual text segments is faster using the new callback (about 30%). Again, this may be different depending on how the styles are returned and whether they are computed dynamically or stored. The benchmark computes the text segments (new code) and the styles (which are used to get the text segments in the old code) dynamically.
For character shaping and bold styles there are 2 cases - the bold range occurs within a segment or the bold range occurs across multiple bidi segments. If the bold range occurs within a bidi segment, the code should work "as is". If the bold range occurs across bidi segments, character shaping across boundaries should not be supported (doing so does not make sense). Need to change the prepareBoldText code to handle the second case.
Released fix into HEAD. Instead of using setBidiColoring customers should register a BidiSegmentListener and explicitly specify reordering segments. Spec is included in BidiSegmentListener/BidiSegmentEvent. Need to deprecate setBidiColoring/getBidiColoing.
In addition to deprecating get/setBidiColoring methods, also need to put in code for bold support and need to contact Kai about the change.
Added code to handle bold and character shaping.
Sent email to Kai. deprecate setBidiColoring and getBidiColoring methods in the next build.
PRODUCT VERSION: 2.006
Deprecated setBidiColoring and getBidiColoring methods. Haven't heard anything from Kai.
Changes released.
