Bugzilla – Full Text Bug Listing
| Summary: | Bidi3.3: Adding new attribute for changing report layout orientation | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Ahmed Farrag <afarrag> |
| Component: | BIRT | Assignee: | Wenbin He <whe> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | clin, foxm, khouly, kitlo, Lina.Kemmel, mfadl, qwang, steven.wasleski, wenfeng.fwd, whe |
| Version: | 2.2.0 | Keywords: | plan |
| Target Milestone: | 2.3.1 | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Ahmed Farrag
When a report or report item is set to RTL, do we expect the report is layout RTL even when the report viewing end user is in a LTR locale? (In reply to comment #1) > When a report or report item is set to RTL, do we expect the report is layout > RTL even when the report viewing end user is in a LTR locale? > Apologies for the late reply. The answer to your question is yes, in analogy to "HTML" pages that can be viewed in RTL (when "dir" attribute is set to RTL) even if end users are running their OS on LTR locale. Has this been added as part of the new RTL feature in 2.3.x? This is now supported to a considerable extent. The new RTL feature provides:
(1) orientation of the whole report,
(2) text direction (a.k.a "reading order") of report element.
However, the requested feature also implies:
(3) orientation at report element level, equivalent to the HTML "dir" attribute
/ CSS "direction" property. Actually, this is a superset of (2), and
includes both direction of text and direction of graphics.
I think in order to add the missing functionality, we can either:
(a) Associate "Bidi layout orientation" property with a design element instead
of report design as at present, and make it inheritable. Rename it to just
'direction'
(b) Introduce a new style property that will express report element orientation
(c) Change semantics of the existing "Bidi text direction" property to work like
'dir'/'direction' in HTML/CSS. Also, rename it to just 'direction'.
I think (c) is preferable. Not (a) because ReportDesign ROM element doesn't accept styles, and introducing some pseudo-style property would probably be somewhat tricky. It's also not (b) because having 2 Bidi styles, one of which is a subset of the other sounds a bit redundant (although there are precedents, e.g. in win32 API).
+1 for (c), but we will need to defer the change to 2.5.0 since we can not change the semantic or name of an existing property in a point release. The features developed already provide the most critical RTL functionality. Implication of the missing feature is mostly a table with a mismatching orientation (i.e. with columns ordered from right to left inside an LTR document or columns ordered from left to right in an RTL document). I think deferring this enhancement to 2.5.0 will not have too serious impact on users. However, following user feedbacks, I suggest to add one associated change to 2.3.1. That is linking text alignment with text direction, but not with the global orientation as at present. The change will leave the semantics and name of the property intact, and it requires pretty minor code modifications. And, as it turned out, by doing it we will provide behavior that matches user expectations. (In reply to comment #7) > However, following user feedbacks, I suggest to add one associated change to > 2.3.1. That is linking text alignment with text direction, but not with the > global orientation as at present. The change will leave the semantics and name > of the property intact, and it requires pretty minor code modifications. > And, as it turned out, by doing it we will provide behavior that matches user > expectations. +1 for this enh. (In reply to comment #8) Thank you, Wenfeng. I will submit proposed changes for text alignment shortly, after their unit test is complete. I filed bug 244375 (Report engine) and bug 244376 (Report designer) to track the alignment changes. Original requirement has been supported in the latest BIRT 2.3.1. bug fixed, closing.... |