Community
Participate
Working Groups
Scenario: 1. Select the <NLprojectName> project in the Navigator view and select the File > New > Other... menu item. 2. Select the UML Model wizard from the Example EMF Model Creation Wizards category and press the Next > button. 3. Enter <NLmodelFileName>.uml for the file name and press the Next > button. 4. Select Model for the model object and press the Finish button. 5. Select the Window > Show View > Properties menu item. 6. Select the <Model> element in the <NLmodelFileName>.uml editor. 7. Enter mixed text: abcABC where capital characters symbolize Hebrew text for the Value of the Name property in the Properties view. 8. Create a package: select the model, Right-click and select the New Child > Packaged Element Package option from the context menu. Enter DEFdef for the Value of the Name property in the Properties view. 9. Create a class: select the model, Right-click and select the New Child > Packaged Element class option from the context menu. Enter <NLpackageName> for the Value of the Name property in the Properties view. 10. Create an association: Select the <Package> <NLpackageName> element in the <NLmodelFileName>.uml editor. Right-click and select the New Child > Packaged Element Association option from the context menu. Enter <NLassociationName> for the Value of the Name property in the Properties view. Select the <Association> <NLassociationName> element in the <NLmodelFileName>.uml editor. Right-click and select the New Child > Property option from the context menu. 11. Click on the Type property in the Properties view. Result: The path: <NLmodelName>:: <NLpackageName>::<NLclassName> is disordered. Instead of: abcABC::DEFdef::<NLclass> the result is: abcDEF::ABCdef::<NLclass>. It might be that speical BIDI characters should be added to elements names for correct ordering.
The algorithm used to construct qualified names is dictated by the UML specification and so cannot be changed. However, if your model is named abcABC and a package it contains is named DEFdef, I would expect the qualified name of every element in the package to start with abcABC::DEFdef. Would it be possible to attach a screen shot showing this problem and/or (ideally) the model that you described?
Created attachment 36956 [details] Screenshot showing the disorder of class path in type property
Created attachment 36957 [details] the uml2 model file
The string being displayed in the UI is somehow different from the string being returned by the text provider.
Kenn - in the text provider, before you return the label string, can you try running it through TextProcessor.process(labelString, "<>"); returning the resulting string from getLabel(Object) and see if the string renders properly. Note that the second string argument should contain any neutral characters (i.e. characters that do not have strong directionality) that could be displayed in your string. Examples are ./\:<>
I cannot make use of the TextProcessor class in UML2 for (at least) two reasons: 1. The org.eclipse.uml2.uml.edit plug-in does not currently depend on the Eclipse platform (nor OSGI). Adding such a dependency would limit the use of UML2 in stand-alone applications. 2. It seems that this processing would need to be done (and undone?) in RTL model regardeless of language, and yet looking at TextProcessor it appears that the string is changed only for specific locales. Why is this? Excuse my ignorance, but why can this processing not be done by the UI controls before rendering the strings instead of expect each individual text provider to do it?
I didn't realize you don't require the osgi plugin. This text processing is only required for BiDi locales because they render right to left, rather then left to right as Latin locales do (which is most other locales supported by eclipse). The bidi algorithm will mangle strings with mixed Latin and Hebrew/Arabic text when neutral characters are present (in some situations, like file paths, URLs and obviously in this case). The TextProcessor inserts directional characters into these strings to make them render correctly in BiDi(RTL) locales but is essentially a no-op in Latin (LTR) locales, returning the same string that was passed in. There may be something the UI can do about views that we own (e.g. Navigator uses a WorkbenchLabelProvider), but as for your editors and views that we do not own I think our hands our tied. I am not sure what generic solution we can provide for the Properties view, I would have to ask the owner. We already have bug 131156 logged for this problem in the properties view.
Kenn, did you try using TextProcessor in your editor as I suggested in comment #5? UML2's editor plugin requires org.eclipse.ui.ide and uses jface which gives you access to the TextProcessor API in osgi that you need.
No. Given that the string is being produced by the item provider (in the platform-independent edit layer below the editor) and that other clients may be using/displaying these strings, I'm not sure it makes sense to change (just) the editor - what about the other clients? Comments like #20 and #23 in bug 131711 concern me... I'm not sure anyone really has a complete handle on the solution to this issue.
Kenn, I have actually discussed at length with Mati solutions to this problem. This is why the TextProcessor API was provided. Mati is an expert in this space. Some of the challenges presented by rendering BiDi text are not easily solved. Basically, the viewers cannot provide a generic solution to this problem because each string that it is presented with cannot be manipulated into segments the same way each time to guarantee proper rendering.
(In reply to comment #6) > I cannot make use of the TextProcessor class in UML2 for (at least) two > reasons: > ... > 2. It seems that this processing would need to be done (and undone?) in RTL > model regardeless of language, and yet looking at TextProcessor it appears > that the string is changed only for specific locales. This processing may need to be done in the LTR direction as well, and indeed - in a locale-independent manner. The need for the processing should be dictated by the text content.
*** Bug 133152 has been marked as a duplicate of this bug. ***
*** Bug 133539 has been marked as a duplicate of this bug. ***
*** Bug 133547 has been marked as a duplicate of this bug. ***
*** Bug 133556 has been marked as a duplicate of this bug. ***
