Bugzilla – Full Text Bug Listing
| Summary: | BIDI3.3:HCG_Mixed BiDi and Latin text are not correctly reordered in PDF report | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Tomer Mahlin <tomerm> | ||||
| Component: | BIRT | Assignee: | Yu Chen <yChen> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | critical | ||||||
| Priority: | P3 | CC: | camle, clin, dmichonneau, doshiro, jasonweathersby, kitlo, Lina.Kemmel, paul, steven.wasleski, swang, wenfeng.fwd, whe, yChen | ||||
| Version: | 2.2.0 | ||||||
| Target Milestone: | Future | ||||||
| Hardware: | PC | ||||||
| OS: | Windows All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Tomer Mahlin
Created attachment 63477 [details]
BiDI text in Report Designer and in PDF Viewer
Sorry, I am not sure if this makes any difference, but since the problem occurs in BIRT 2.2 the version of itext mentioned in Setup is incorrect. It should be itext-1.4.6.jar instead of itext-1.3.jar. We are not able to completely fix the bug at present. Because BIRT layout engine can not deal with texts whose base run direction is right-to-left.
For PDF output, we reverse the right-to-left text to make the visual order right.
However, some problem can be fixed soon. For the case mentioned in the bug,
HELLO 123 world
hello WORLD FRIEND 123 abc
Expected result:
123OLLEH world
hello 123 DNEIRF DLROW abc
the result can be
OLLEH 123 world
hello DNEIRF DLROW 123 abc
we have fixed partially, defer the remaining to future release. Is there a way to tell the 123 is part of the BiDi text and hence needs to be part of the flip of the word sequences? The Unicode standard (which is the only standard addressing this subject) states that numbers go with the preceding text. In our case, "123" goes with the RTL segment which precedes it. For more details, see http://www.unicode.org/reports/tr9 In addition to comment #6, note that after being flipped as part of the RTL segment, the number must be flipped once more so that its final display is still "123". I am not sure why are you reinventing the wheel ? Unicode BiDI algorithm which should be applied on the buffer was not once implemented. As was mentioned in bug 129567 this algorithm was implemented in IBM JDK. You can simply decompile the JDK and learn how to implement it. In addition Windows also provide implementation of this algorithm via Uniscribe set of services: * http://en.wikipedia.org/wiki/Uniscribe * http://www.microsoft.com/typography/developers/uniscribe/default.htm In addition, please notice that BIRT uses itext Java PDF library to generate PDF files (http://www.lowagie.com/iText/). This library does have built-in BiDi engine. Have you tried to use it ? Finally from my personal experience with Actuate products I can say that Actuate 8 (FP 5) probably the only product which does have perfect support for BiDi text in PDF reports. Actuate 8 allow you generation of reports in various formats including PDF. PDF reports including BiDI data and generated with Acutate 8 has perfect display of BiDi data. As far as I understand BIRT is mostly handled by Actuate company (this is self evident from the list of PMC members and people handling BIRT related defects). Why can't you use the same solution you have in Actuate product for BIRT ? What kind of additional guidance you would like to receive from BiDI centers ? Resolving this issue takes more than 2 years .... Please ignore most part of the previous comment (comment #8) for the following reasons: 1. It is not prudent to decompile some existing code as there can easily be legal concern around that. 2. A solution specific to Windows would not be general enough to support the non-Windows platforms (like Linux). 3. Whether the solution from an existing Actuate product can/would be applied to BIRT is really under the discretion of the Actuate company and its contributors to the BIRT project. We will look into using iText's BiDi util. I believe this was fixed in 2.3.0. Can anyone resolve and verify this bug please? It should be fixed by a patch added to bug 228244. In sum, there are 3 bugs supposed to be covered by this patch: - bug 129567 - bug 181909 (this one) - bug 228244. Yes, the bug has already been fixed. |