Community
Participate
Working Groups
As of today, global layout orientation of report design and output (except for HTML output) is not addressed. This bug is to introduce/enhance support for report design orientation.
Created attachment 94390 [details] Patch against the trunk This attachment includes API-related changes and some essential implementation sequences to support design orientation. Some changes highlights: 1. Report metadata schema and rom.def are updated to back most of Bidi properties we are planning to address. 2. Added a new class BidiPropertyDefn that extends org.eclipse.birt.report.model.metadata.SystemPropertyDefn and holds metadata information for Bidi properties. 3. New API methods added: 3.1. org.eclipse.birt.report.model.api.ReportDesignHandle#getBidiOrientation 3.2. org.eclipse.birt.report.model.api.ReportDesignHandle#setBidiOrientation 4. Added a new utility class org.eclipse.birt.report.engine.util.BidiAlignmentResolver which provides some convenience methods for text alignment resolution.
I would like to emphasize that attachment 94390 [details] apply to ROM, Design engine and Report engine - generation phase. Changes for report output will be supplied in a separate attachment.
Comment on attachment 94390 [details] Patch against the trunk More information: The major goal of these changes is: - extend the BIRT Report Object Model with Bidi properties, - provide API to manipulate these properties programmatically, - allow (de)serialization of these properties into report model and design XML file. 1. Model changes 1.1. Bidi properties introduced to the ROM are as follows: 1.1.1. At ReportDesign element level: property element named "bidiLayoutOrientation" that controls the global orientation of the root report model element. 1.1.2. At OdaDataSet element level: 1.1.2.1. Property group "bidiFormatMetadata" - indicates Bidi format of meta-data (table, column, field names) used to access a data source. 1.1.2.2. Property group "bidiFormatContent" - indicates Bidi format in which the data content is stored in the data source. Each of the two groups unites the following properties: - "orderingScheme". Bidi ordering scheme according to which strings are reordered. Choices can be logical or visual. - "orientation". Reading order of text. Can be left-to-right, right-to-left contextual left-to-right or contextual right-to-left. - "symSwap" (symmetric swapping, a.k.a. "character mirroring"). Indicates whether mirrorable characters (such as parentheses) are stored in buffer in a mirrored or nominal form. Can be yes or no. - "textShaping". Arabic-specific property, which indicates whether characters are stored in buffer in a shaped form or not. Can be nominal or shaped. - "textShaping". Arabic-specific property as well, which indicates numeric shapes of characters in buffer. Can be nominal, national or contextual. 1.1.3. At Style element level: property element named "bidiTextDirection" that controls the reading order of the associated design element. (Note that rom.def also contains a number of StyledProperty elements added to all those report items which have the "textAlignment" property. This seems redundant for the moment, since the property is already defined by a Style and, consequently, will be available for all report items that have a style. However, it is meant to be used in the future.) All the above properties are Bidi-related. To indicate that, the corresponding property element definitions are attributed with the "isBidiProperty" attribute (declared in metadata.xsd schema). This attribute is intended to be utilized when deciding if the given property is visible in Designer UI. 1.2. New Design Engine API methods: - org.eclipse.birt.report.model.api.ReportDesignHandle#getBidiOrientation: retreives the Bidi layout orientation property. - org.eclipse.birt.report.model.api.ReportDesignHandle#setBidiOrientation: sets the Bidi layout orientation property. - org.eclipse.birt.report.model.api.DesignElementHandle#isDirectionRTL: examines whether the resolved direction of the given model element is right-to-left or not. 1.3. New public constants added to the org.eclipse.birt.report.model.api.elements.DesignChoiceConstants interface: - public static final String CHOICE_BIDI_ORIENTATION = "bidiLayoutOrientation"; - public static final String BIDI_ORIENTATION_RTL = "Right To Left"; - public static final String BIDI_ORIENTATION_LTR = "Left To Right"; - public static final String CHOICE_BIDI_DIRECTION = "bidiTextDirection"; 2. Report engine 2.1. The default for text alignment style was changed from the static "left" to remain empty and get resolved dynamically to the value consistent with the report design orientation. Code affected: 2.1.1. org.eclipse.birt.report.engine.css.engine.BIRTPropertyManagerFactory constructor: the default text alignment value is set to null. 2.1.2. A new method - org.eclipse.birt.report.engine.parser.StylePropertyMapping#getDefaultValue(String name, ReportDesignHandle handle) - will be responsible for obtaining a dynamic default for the text alignment style based on the orientation of the given report design handle. 2.2. New custom style constants related to Bidi orientation were defined: - String BIRT_LTR_VALUE = "Left To Right"; - String BIRT_RTL_VALUE = "Right To Left"; 2.3. New matching values were added to the org.eclipse.birt.report.engine.css.engine.value.birt.BIRTValueConstants interface: - Value LEFT_TO_RIGHT_VALUE - Value RIGHT_TO_LEFT_VALUE
> - "textShaping". Arabic-specific property, which indicates whether characters > are stored in buffer in a shaped form or not. Can be nominal or shaped. > - "textShaping". Arabic-specific property as well, which indicates numeric > shapes of characters in buffer. Can be nominal, national or contextual. There was a typo: the last property should be called "numericShaping". Also, I would like to slightly reword its description: - "numericShaping". Arabic-specific property as well, which indicates the decimal range used to represent digits in buffer. Can be nominal, national or contextual.
In ROM, the OdaDataSet element level bidi properties has been added: Property group "bidiFormatMetadata" and the Property group "bidiFormatContent". However, didn't see corresponding changes in source codes. Is this part missed or has not been used yet? After reading codes, think BidiPropertyDefn is not required. This is inconsistent with current property definition design. Need comments from Data team to see how to handle Bidi with the data sources/data sets.
Created attachment 95380 [details] Revised patch Resubmitting the patch with the following changes: 1. Removed BidiPropertyDefn - as we no longer apply Bidi-enablement settings, it became useless. (However "isBidiProperty" attribute still remains in metadata.xsd and rom.def. If "User customizable UI" feature Zhiqiang mentioned in another bug will be implemented, this attribute could be in use.) 2. Added Bidi Data source format related API to org.eclipse.birt.report.model.api.DataSetHandle: - getMetadataBidiFormat - setMetadataBidiFormat - getContentBidiFormat - setContentBidiFormat 3. Removed changes for DesignElementHandle, EngineIRVisitor, BIRTPropertyManagerFactory, and StylePropertyMapping. They will be submitted to bug 225180 to back both orientation and direction properties.
Since the Bidi-enablement notion is not applicable anymore, it seems I need to revert |pdfBidiProcessing| implementation back. Also, it will be necessary to synchronize the patch with the current code base. Please let me know if it's OK to resubmit the patch (and when...)
Lina, comments from reviewing the patch: 1) Are we going to support the element level orientation? From your patch,(from another bug patch) looks like each styled report item can set the bidiTextDirection property, will this setting overridden the one on ReportDesign? 2)Choice set: bidiLayoutOrientation and bidiTextDirection defined the same choice constants. So, can we just keep one choice and rename it to bidiDirection.Then from ReportDesign and Style element, the detail type of the bidiProperty can refer to " bidiDirection". 3) you defined Class.BidiUtils in ROM. Is this class supposed to be used in script? I think DtE gets the classes definitions from an extension point. I will double check with Data team.
(In reply to comment #8) Thanks for the review. > 1) Are we going to support the element level orientation? Yes, we are going to support element level orientation, although it's not defined explicitly at that level. > From your patch,(from another bug patch) looks like each styled report item > can set the bidiTextDirection property, will this setting overridden the one > on ReportDesign? Orientation aggregates 2 properties: direction of text and orientation of graphics. Styled item will override ReportDesign's text direction only. > 2)Choice set: bidiLayoutOrientation and bidiTextDirection defined the same > choice constants. So, can we just keep one choice and rename it to > bidiDirection.Then from ReportDesign and Style element, the detail type of the > bidiProperty can refer to " bidiDirection". Yes. Formerly, choice constants for bidiTextDirection were "ltr" and "rtl" to match those in HTML/CSS. Although at present bidiTextDirection doesn't have the same semantics as the CSS direction does, we kept the distinct constants so we will be able to support the CSS direction equivalent in future. Please indicate if at this point you prefer to maintain just 1 constant though. > 3) you defined Class.BidiUtils in ROM. Is this class supposed to be used in > script? ... Yes.
(In reply to comment #8) > > 1) Are we going to support the element level orientation? > Yes, we are going to support element level orientation, although it's not > defined explicitly at that level. Sorry, it seems in the context of report model a better answer would be "No". At element level orientation will affect the element presentation only.
OdaDataSetHandle defines get/set methods for bidiFormatMetadataStr and bidiFormatContentStr. While, there are no methods for properties defined in two property groups. <PropertyGroup displayNameID="Element.OdaDataSet.bidiFormatMetadata"> <PropertyGroup displayNameID="Element.OdaDataSet.bidiFormatMetadata"> Does this mean values in each property group constructs the corresponding bidiFormatXXXXStr? Or, are these properties defined in group is necessary?
Created attachment 96055 [details] ODA Data Set Bidi properties in the Property editor These properties are serialized to model and streamed to report XML in a form of XXXXX string. Individual properties from a group are used in Eclipse designer Property Editor as shown in the screen shot.
please wait for the result of IP review before merging the code to BIRT 2.3 CVS. To check the status of IP review at https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2260
(In reply to comment #12) > Created an attachment (id=96055) [details] > ODA Data Set Bidi properties in the Property editor > > These properties are serialized to model and streamed to report XML in a form > of XXXXX string. Does this mean that the serialized string is bidiFormatMetadataStr/bidiFormatContentStr? My question is that whether there is any relationship among "ODA Data Set Bidi properties" and "bidiFormatMetadataStr/bidiFormatContentStr". If has, how and where to define the serialization/de-serialization algorithm? Didn't see any method in DataSetHandle for such issue. BTW, if define these properties in OdaDataSet, it is better to add methods on OdaDataSetHandle instead of DataSetHandle. > > Individual properties from a group are used in Eclipse designer Property Editor > as shown in the screen shot. >
(In reply to comment #14) Rick, per Data team's comments, we will be moving Data changes to a Bidi extension (which I think could be rather a OdaDataSet extension, not a OdaDataSource one). It looks like the OdaDataSet Bidi properties then can be defined in that extension instead of the basic ROM. So it looks like I will need to discard Data-related structure changes from the patch attached here. Sorry about the inconvenience. > (In reply to comment #12) > > Created an attachment (id=96055) [details] [details] > > ODA Data Set Bidi properties in the Property editor > > > > These properties are serialized to model and streamed to report XML in a > > form of XXXXX string. > > Does this mean that the serialized string is > bidiFormatMetadataStr/bidiFormatContentStr? > Yes. > My question is that whether there is any relationship among "ODA Data Set Bidi > properties" and "bidiFormatMetadataStr/bidiFormatContentStr". If has, how and > where to define the serialization/de-serialization algorithm? Didn't see any > method in DataSetHandle for such issue. > "ODA Data Set Bidi properties" is a decomposition of "bidiFormatMetadataStr/ bidiFormatContentStr". We didn't consider the serialization/de-serialization implementation as basic changes and thus didn't include them with the patch.
Created attachment 96624 [details] Patch without Data changes Removed Data changes. Also, now we use 1 choice constant as suggest by Ivy in comment #8. I agree it's preferable to have the same name for both properties anyway.
(In reply to comment #16) > it's preferable to have the same name for both properties anyway. > - i.e. for property choices' names.
The IP review is complete, and this submission is now approved.
Patched on Model codes. Since also contains Engine patch, reassign to Engine team.
BidiAlignmentResolver from this patch (96624) is now added to bug 225180.
Fixed.
Comment on attachment 96624 [details] Patch without Data changes per Ganymede IP log
Verified. Closing.
