Apache OpenOffice (AOO) Bugzilla – Issue 17514
incorrect letter order / word order when exporting Hebrew as swf (flash)
Last modified: 2013-08-07 15:01:09 UTC
When exporting a Hebrew presentation from impress to flash, it brakes completely. * word order is incorrect * letter order inside words is incorrect- hebrew HELLO becomes OLLEH
Created attachment 8080 [details] original impress file
Created attachment 8081 [details] exported flash file
Created attachment 8082 [details] screen shot- the file in flash
Created attachment 8083 [details] screen shot- the file in impress
DL->CL: Would you please takeover?
will have a look
set target milestone
.
"According to the OpenOffice.org roadmap (http://tools.openoffice.org/releases) this issue was retargeted to OOo Later."
dina: fwi. I wonder how the press reviews of Hebrew OO missed the fact that this feature is cxompletly broken?
this is true for Draw as well. When it comes to Hebrew, flash export is completely broken an unusable. Any chance that this will be fixed by version 2?
Created attachment 12101 [details] original draw file with Hebrew
Created attachment 12102 [details] exported flash from draw 1.1/ Compare the Hebrew tot he original
*** Issue 26903 has been marked as a duplicate of this issue. ***
First: Issue 35441 is duplicate of this one. Second: OOo 2.0 is out and working and this issue, well... Is still an issue! Did any one took a look at it since Oct 13, 2004? Flash export is a grate feature in open-office, but as of now it is useless for Hebrew users.
*** Issue 35441 has been marked as a duplicate of this issue. ***
updated version info
this bug is 3 years old and has 70 votes. Any chances on getting it back on the roadmap?
ayaniger->cl: Have you been able to look at this issue? If not, can you give me direction on how to deal with it (where to look in the code, is there existing documentation, related bugs, etc.)?
Any news on this front?
yba->Alan: Let me know where you think that we stand on the Hebrew PPT->Impress project. Either you can fix this bug after you make more progress on PPT->Impress , or I could assign the fix to Moshe since it *appears* to be not connected with other work that you are currently doing on Impress. Let me know what you think. - yba
retargeted due to the high vote count. cl->ayaniger: thanks for you offer to help, I will try to have a quick look at this issue soon and then see if I can give you some hints or need some help for you to fix this
can someone please verify if we have the same issue with svg?
cl, I checked the svg support with Arabic and Hebrew but unfortunately, I couldn't see any text. I checked with Firefox, Konqueror, Opera and ksvg in linux.
yba->cl: Please assign this issue to Alan Yaniger. We have started work on it.
ayaniger->cl: I noticed that in swfwriter1.cxx, in Writer::Impl_writeActions, there is no case statement for META_TEXTLANGUAGE_ACTION (like there is in pdfexport.cxx). When I added one, execution reached the code I added. Might this be the problem? If so, we need an "Impl_setLanguage" function, or the like.
reassigning as requested cl->ayaniger: that may be true, but you are on the right track. Comparing pdf and svg export with flash is a good start to find out what is missing.
ayaniger -> cl: I think you've mixed up your "alan"'s. :) My first name is Alan, but my OOo name is "ayaniger". You assigned the issue to "alan" (ahmad azlan) instead of "ayaniger". Alan Yaniger
Correcting reassignment
yba->cl,ayaniger,alan: Sorry, this is my fault. I thought that "alan" was a duplicate alias for "ayaniger".
cl->alan: As soon as you have a fix, I'm happy to review it and maybe put it in a CWS for integration
ayaniger->cl: For now, I hacked a solution by passing the reversed text through the bidi algorithm, thus reversing the reversed text, and getting the text reordered. Intending to really solve the problem when I have more time, I've refrained from posting the patch until now because it's such a kludge. But I'll post it anyway, since it may be useful for the time being.
Created attachment 40585 [details] Passes text through bidi algorithm
cl->ayaniger: I don't understand hebrew so I can only verify that this patch only hack hebrew text. I also see that this is only a hack. Question is, does it make things only better for hebrew export? Should we integrate it as it is now? Or does it break other things?
ayaniger->cl: There is no doubt that this patch makes things only better for Hebrew. In the current version, all Hebrew text is simply backwards, which is about as bad as you can get. I've looked at the Flash export code again recently and compared with SVG export. I found that the Hebrew string retrieved from the metafile is in the same order for both Flash export and for SVG export, yet in SVG, the string is displayed in proper order, while in Flash it isn't (unless you apply my patch). Since I haven't worked with the SVG export code at all, I think it might be a good idea at this point to hand the issue over to someone who is more familiar with the SVG and Flash code. Since the issue was originally assigned to you, I guess you are that person. If you have the time now to look into it and find a more elegant solution fairly soon, maybe you'll want to do that before integrating the patch. If you don't have time for that now, Hebrew users would be grateful if you integrate the patch, and at some point one of us can look further into the problem. I will update you if I go back to working on the issue, and if you don't mind, I would appreciate it if you update me if you begin work on the issue. From my tests with English text, my patch doesn't break anything, but your QA people may want to confirm this.
ok so I target this issue for 2.2. I will either find time to have a look at this prior to 2.2 code freeze or integrate this patch for 2.2 before code freeze. Whatever comes first :)
cl: what about your promise? ;-)
good news is I fixed this issue, not only for hebrew but for all asian and complex text. When exporting text I check for bidi and asian/complex script. In that case I ask the vcl outputdevice for a polygon representation of the text. This works always as all our text formating functionality is already implemented in vcl. This also solves the problems for languages where one character could be rendered with different glyphs (polygons) depending on the context. The drawback is that exporting bidi/asian/complex text will create bigger swf files as glyph polygons are currently not reused. I will ask on the mailing list, maybe someone likes to dedicate some time on this issue.
verified in cws, back to qa
CGU: Verified in cws impress116
Integrated in src680m203 and OOF680m6