| Summary: | Add BIDI support to BIRT charts | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Mohamed El-Kholy <khouly> | ||||||||||
| Component: | BIRT | Assignee: | Yulin Wang <Lionel.wyl> | ||||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | bluesoldier, clin, fira, foxm, khouly, Lina.Kemmel, Lionel.wyl, mfadl, moharram, whe | ||||||||||
| Version: | 2.3.0 | Keywords: | plan | ||||||||||
| Target Milestone: | 2.3.0 RC1 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | Autoed,G | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Mohamed El-Kholy
Created attachment 94788 [details]
BIDI support for Charts engine
Will this bug be used to track the chart engine API change? As discussed, if we just add the text_direction property to chart report item level, it's better to add it as a ROM property by which you don't have to change the EMF model. Reassign to chart team to review the change. (In reply to comment #2) > Will this bug be used to track the chart engine API change? > > As discussed, if we just add the text_direction property to chart report item > level, it's better to add it as a ROM property by which you don't have to > change the EMF model. > > Reassign to chart team to review the change. > I agree with you. Of course adding property to chart model is fine as well. You only need to modify EMF and generate the code. Simply modifying java code like patch is not enough. Regarding adding property in ROM, this property could be serialized in chart's ExtendedItemHandle by report model, and chart Generator will set this property to RuntimeContext. Chart renderer will get it and render with specified direction. Created attachment 95144 [details]
New one based on previous patch
I created a new patch based on the previous by removing model property.
Now developer should invoke RuntimeContext.setRightToLeft to set the direction.
This method has been used in several places.
Here are used reference as follows:
1. set report engine's HTMLRenderOption
2. set eclipse command "-dir rtl"
3. check the rtl locale. This is removed in patch.
If we need UI to set the direction, add a property in handle as mentioned above.
Thanks a lot for your responses. We've tried to update EMF and generate the code, as per the note previously sent by Yulin, but the resulting chart code files were almost empty and only contained the packages import section. Are there any special requirements in order to have EMF generate the code properly? For your suggestion regarding the use of RuntimeContext.setRightToLeft(), I would like to clarify that from bidi user's perspective, we need to have chart legend bidi layout change according to the changes in report bidi orientation while chart bidi text direction change according to the value of the charts text direction property. We already use RunTimeContext.setRightToLeft() to set chart legend bidi layout according to reports bidi orientation (the updates were planned to be attached in a different patch). Currently we are trying to add new methods to RunTimeContext to have charts bidi text direction reflected while rendering chart text. This means that RunTimeContext objects will maintain two bidi properties, one for report bidi orientation which affects legend bidi layout and the other for text bidi orientation which affects chart text bidi reading order. Finally, could you please elaborate more on adding new property to handle and guide us to do charts bidi support in the best way? (In reply to comment #2) > As discussed, if we just add the text_direction property to chart report item > level, it's better to add it as a ROM property by which you don't have to > change the EMF model. Please note that this property is already added to ROM in patch to bug 225140 (attachment 94390 [details]). When running a build with this patch applied, I can see this property is available to charts. Created attachment 95287 [details]
Horizontal bar charts shown as a crosstab measure
An additional item that has come up is the mirroring of crosstabs that show their measure cells as charts. If a crosstab uses a RTL orientation, the row headers will appear on the right-hand-side of the crosstab. Please refer to the attached image. If this crosstab were drawn in RTL orientation, the bars would need to be drawn from right to left, with the x-axis on the right hand side of the chart. What this really means is that we must reverse the scale of the y-axis (the x-axis would still be drawn at y=0, but y=0 would appear on the right of the y-axis with increasing values to the left). Also note that in this case it doesn't make sense for the crosstab and the chart drawn in its cells to have different values for the orientation. The chart should inherit the orientation setting from the crosstab. Created attachment 95756 [details]
An addition to the previous patch "95144" to add a new attribute to the runtimecontext for the text direction
This small addition to RunTimeContext should allow adding a new variable to the class for the text direction, calling those methods could be added in defect fixing phase
The IP review is complete, and this submission is now approved. Added following BIDI support in chart engine. 1. Added method in RuntimeContext to set text direction. 2. Set chart direction from design element handler to runtime context 3. Set text direction from StyleHandle to runtime context 4. Render rtl text in chart renderer 5. For the xtab integration case, adjust label direction in axis chart, and reverse category in plot chart. 6. Also added method in ChartWizardContext to set text direction, and revised bidi support in UI Comment on attachment 94788 [details]
BIDI support for Charts engine
per Ganymede IP log
Comment on attachment 95144 [details]
New one based on previous patch
per Ganymede IP log
Comment on attachment 95756 [details]
An addition to the previous patch "95144" to add a new attribute to the runtimecontext for the text direction
per Ganymede IP log
Closing the bug |