Community
Participate
Working Groups
Report Designer should offer UI options regulating Bidi enablement and default Bidi settings - orientation and Data source format. Our initial intention was as follows. Bidi-enablement settings will control Bidi capabilitites in all BIRT components enabled for Bidi. In addition, there would be API allowing suppressing or enabling Bidi functionalities in Design- and Report engine. However, based on Wenbin' comments to the Bidi design specification, Bidi support should *always* be enabled in the Report engine. So I assume that Bidi enablement settings will only toggle visibility of Bidi options in Designer GUI and visualization of these options in Designer canvas.
Created attachment 94745 [details] Patch against the current trunk These changes are to contribute a Bidi preference page. They also include some strings to be used by subsequent Bidi code submissions. The code is largely contributed by Ira Fishbein.
Bidi support in UI should also always be enabled. There're actually three options for each bidi property: Auto(unspecified), LTR, RTL. When it's "Auto", it uses current locale to determine the behavior.
(In reply to comment #2) You are talking about the way Bidi properties should be resolved, which would happen regardless of the fact whether they are visible in GUI or not. We know that some users are not interested in seeing Bidi UIs. On the other hand, always hiding Bidi options from such users, we dramatically decrease their chances to acquire Bidi functionalities and apply them in multilingual report development. So we decided to always (in locale-independent manner) have these options accessible to report developers, but allow them to switch visibility of these options as needed. What we could do is to drive the *default* Bidi-enablement state from the locale. I believe it should rather be the system-wide locale (as opposed to the report locale or even Eclipse OSGi locale) - which the most reliably indicates the user locale preferences. Furthermore, I suggest to have fixed defaults, which for orientation/direction will be always LTR. This complies to standards and mimics the native platform behavior.
> I suggest to have fixed defaults, which for orientation/direction will be > be always LTR. This complies to standards and mimics the native platform > behavior. Actually, this would *mostly* match the platform behavior. __________ Zhiqiang, does it make sense?
I think I need revise my last comments "When it's "Auto", it uses current locale to determine the behavior." as "When it's "Auto", if it has a container, it uses the inherited value; if it's the top level element, it uses the default value according to current locale". but I agree we can have a fixed default for top level element if that mostly matches the platform behavior. The question is about the bidi-enablement settings, which is not part of the report model but a pure UI setting. Is that just used to control the visibility of UI functionalities? If that's true, I don't think we need it at this time. Currently we never hide any functionality through UI preference. That's rather a "User customizable UI" feature which we haven't addressed yet. But maybe we can have a better global design in future.
(In reply to comment #5) > The question is about the bidi-enablement settings, which is not part of the > report model but a pure UI setting. Is that just used to control the > visibility of UI functionalities? Yes. (The initial Bidi design and implementation intended to use it to control the overall Bidi functionality in report model, report engine and Designer UI. There was implemented a class variable maintained in sync with the UI settings - org.eclipse.birt.report.model.core.DesignSession#bidiEnabled - and SessionHandle API to control it programmatically.) > If that's true, I don't think we need it at this time. > Currently we never hide any functionality through UI preference. That's rather > a "User customizable UI" feature which we haven't addressed yet. But maybe we > can have a better global design in future. Okay, I see. So to confirm: I will back Bidi-enablement settings out and resubmit the patch. The patch will still include the Bidi preference page, but that page will only present the default orientation settings. In future, there will be also Data source Bidi preferences. Zhiqiang, if the above is acceptable, please indicate how we resolve orientation in the following scenario: Designer user opens a report that doesn't contain any orientation markup, while the orientation preference is RTL. (Our current implementation assumes that the top-level container is still LTR, and the RTL orientation only applies to a newly created design.)
(In reply to comment #6) > Zhiqiang, if the above is acceptable, please indicate how we resolve > orientation in the following scenario: Designer user opens a report that > doesn't contain any orientation markup, while the orientation preference is > RTL. (Our current implementation assumes that the top-level container is still > LTR, and the RTL orientation only applies to a newly created design.) > I think current assumption is ok, we can just change the preference description to "Use this orientation when create a report design" to make it clear.
Thanks. Should this description go to the context-sensitive help content, or be displayed in the preference page itself?
please wait for the result of the bidi contribution IP review. You can find the detail at https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2260
Created attachment 96697 [details] Patch without Bidi-enablement changes
The IP review is complete, and this submission is now approved.
Comment on attachment 96697 [details] Patch without Bidi-enablement changes per Ganymede IP log
Fixed.
Verified.
