Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | BiDi defaults are platform dependent for undefined base text flow direction | ||
---|---|---|---|
Product: | Internationalization | Reporter: | hdu <hdu> |
Component: | BiDi | Assignee: | AOO issues mailing list <issues> |
Status: | ACCEPTED --- | QA Contact: | |
Severity: | Trivial | ||
Priority: | P3 | CC: | issues, nesshof, xslf |
Version: | OOo 1.1 | ||
Target Milestone: | --- | ||
Hardware: | Other | ||
OS: | All | ||
URL: | http://porting.openoffice.org/servlets/ReadMsg?msgId=955753&listName=dev | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
hdu@apache.org
2003-11-24 16:50:35 UTC
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. 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". |