Apache OpenOffice (AOO) Bugzilla – Issue 22809
BiDi defaults are platform dependent for undefined base text flow direction
Last modified: 2017-05-20 11:13:35 UTC
In the mail to the porting list by Jonathan Ben Avraham it was pointed out that there are different default behaviours regarding BiDi for strings where the base text flow is undefined. The difference is visible for WIN and UNX platforms in the UI, when there is mixed RTL and LTR text.
See http://porting.openoffice.org/servlets/ReadMsg?msgId=955753&listName=dev for the mail that triggered this issue.
Fixed in SRX645 CWS vclpp3bugs and SRC680 CWS vcl20. On UNX platforms vcl now no longer tries to guess the default text direction, which corresponds to todays behaviour of the WIN platform. If the RTL is not set for a text it is assumed that the text is LTR.
HDU->US: please verify on CWS vcl20 (using an EditField on Win and Unx). The request in Jonathan's mail mentioned above, that it would be ideal if it was possible to explicitly specify the base direction of the text flow in UI strings, is not easily implementable in our current resource system. The other alternative, which has been implemented here, is to always treat strings as having a default base direction of left to right. As a rule of thumb everything that looked right on Win will still look ok. Only localized strings with mixed LTR and RTL text that were ordered wrongly on Win platforms have to be checked. Sorry for inconvenience, but the alternative of adding a default direction to every string would be at least as much work.
current implementation of fix reveals regression regarding rendering of western text on Win32 platform.
The noticed problem seems to be a glyph fallback issue and still occurs after removing this fix from the cws. Setting a GUI font substitution "Andale Sans UI" -> "Tahoma" workarounds the issue. US->US: testing hint: the status line in Writer shows the difference: "INSERT" (Linux) vs. "TRESNI" (Win32).
US->US: noticed glyph fallback issue seems severe and needs further investigation regarding regression.
set status to fixed
US->MH: not sure what made you think that the task was fixed. We actually turned down the fix in vcl20 because of assumed regression. The latter now is evaluated and addressed and this fix should be checked-in again on another cws for detailed testing. Reopening.
Changing Owner back to HDU. Unfortunately now we'll probably miss the Target OOo1.1.2.
With a heavy heart changing Target to OOo1.1.3.
scheduled to 1.1.4.
Compare http://www.w3.org/TR/REC-html40/struct/dirlang.html#h-8.2.4
Retargeting as agreed with SBA and US. The problem with the complex interaction between Unicsribe's BiDi, ICU's BiDi and VCL's merging of the two results while synchronizing different font related APIs e.g. for PDF export and considering features like glyph fallback it has shown that a change for OOo 1.1.x is too risky now.
not really a feature
target as discussed with cp
Reset assigne to the default "issues@openoffice.apache.org".