Known Issue: Dynamic Precision designs spacing issues in RTL languages
Microsoft Dynamics AX 2012
WHAT IS THE ISSUE?
Pattern – Precision designs containing columns in a tablix control which are hidden using dynamic expressions. These expressions are commonly used to evaluate the report data set or parameters. For example, if the type of purchase order affects the columns displayed in the report it may be affected by this issue.
Description – the following diagram illustrates the impact of the issue on a dynamic tablix in a precision design.
LTR Languages: In cases where tablix columns in the middle of a larger set of columns are being hidden using dynamic expressions, the columns to the right shift to consume the space leftover by the hidden columns.
RTL Languages: The two middle columns are hidden by expression logic, and the table is rendered having half the size of the page and align to the left edge of the report like it does for LTR views of the tablix control. The columns again have shifted to the left instead of collapsing to the right to maintain the appearance of being right aligned.
EXPECTED: The tablix control shifts to the right so that the column on the far right is aligned with the outer edge of the report in RTL languages.
ASSESSMENT: Tablix controls do not expose a property to control the direction columns are collapsed. Columns are collapsed to the left in all cases. The SSRS Team is aware of the issue and will evaluate a framework enhancement to address this scenario in a future release.
WHICH REPORTS ARE AFFECTED?
The following list contains the characteristics of a report scenario that may be affected by this issue:
- RTL languages like Hebrew & Arabic
- Precision designs containing dynamic tablix controls
- Ledger Journal
- Expense Distributions
- Purchase Order
WHAT IS THE RECOMMENDATION?
Create RTL specific designs of the report and use initialization logic or configuration keys to route users to the design appropriate for the user’s language. This information is accessible in Controller objects for those reports that go through initialization logic.
And, creating a RTL design from an existing report design is a snap using VS Tooling. It’s just a matter of capturing the RDL generated in VS and using it to create a second report for RTL languages.
Suggested naming contentions: [Design name]_RTL
There’s no need to change any of the data set processing logic or parameter experience. However, you will need to disable the RTL Transformation property of the Report design to prevent the framework from swapping controls at run-time.
Request for feedback: Interested in seeing this first hand? If so, let me know and I’ll demonstrate the process for you.