Apache OpenOffice (AOO) Bugzilla – Issue 16295
directionality lost when exporting a presentation to html
Last modified: 2013-08-07 15:02:43 UTC
When exporting a Hebrew presentation from impress to the text HTML version- all directionality settings are lost. Notice list esp. The HTML should have dir=rtl in the proper places to preserve the directionality.
Created attachment 7312 [details] a zip file with the original presentation and the exported html
can you please confirm?
I'm getting all slides as pictures. But it gets my name(as text) and all text in pictures correctly R2L'ed. Even with identation. BTW I !!Think(not sure)!! adding dir=r2l is a bad idea as (1) it doesn't help directionality (2) it forces English text to be R2L too.
DL->CL: Would you please takeover?
DL: Reassigned to Christian.
I think rtl features in impress/draw html export should be looked at in general
still broken in 1.1.0, and the milstone is still "OO later", not even 2.0
This is worse with M65- text overlaps, and the numbering is incorrect. See attachments.
Created attachment 21265 [details] A simple RTL slide created with M65
Created attachment 21266 [details] HTML file created from the slide- notice the overlapping, lack of RTL, and wrong numbering
ayaniger->cl: It looks good when I export the sample file to HTML in 2.0.3, both Linux and Windows.
ayaniger->cl: This issue's status is "Started", but it looks fixed to me. Is there a need for more work that I don't know about?
cl->ayaniger: really? html export was not changed for a long time now, maybe you just looked at the text in the exportet graphics?
ayaniger->cl: Yes, you are right. I was looking at the graphics. However, there is nevertheless a change in the HTML text file for the better. The overlapping is gone, and the bullets look ok. I'm attaching an HTML text file exported from the sample rtl_pres.odp.
Created attachment 44674 [details] HTML created from bugdoc using 2.2
ayaniger, The exported html/xhtml is ltr. The bulleted list should be rtl as in the .odp file. I confirm the bug is still available.
Can someone confirm the bug with 2.4.0 ? Any news about this issue? It has a lot of votes...
retarget issue to 3.1
cl->cl http://www.w3.org/International/tutorials/bidi-xhtml/
sorry to come back to this issue so late but I need more input. On a current OOo300m10 the text is rendered different, but I'm not sure if is now better. But the exported text renders the same in impress and in firefox 3. So where is the error? If someone could maybe provide a version of the html that is 'fixed' so I can see the differences? I would love to fix this issue for 3.1 but I need help.
@cl: Thanks for your return back I can only now test with OOO300m9 and the problem is not just for RTL languages it's also for English as I can see it. The problem is OOo doesn't explicitly export any css aligning and direction rules for text in paragraphs and table cells. If I had centered a text for example in my presentation and exported it to html, it would appear left-aligned not centered. koffice is doing it right I believe in case this may help comparing.
@munzirtaha, could you please attach a zipped version of a koffice export with rtl? I was not able to find out how to do this. @all, I'm still very grateful for anyone who give me a 'fixed' version of the attached bugdocs by just editing the wrong html code. The usage of rtl in html is still confusing for me.
Created attachment 58198 [details] The OOo file
Created attachment 58199 [details] The manually fixed version
Created attachment 58200 [details] The orignal exported html
thanks munzirtaha, so the solution is to add the rtl style to all list items/pargaraphs and spans that are rtl in office. Guess I can do this
@cl: exactly and don't forget tables, too. This would be the basic support needed. Other glitches, if any, could be filed after we have a basic support.
I just figured out that we actually have two different html exports in impress. I fixed the html export that also creates images for slides as this is the one sforbes was reffering to when he wrote this issue and not the xhtml export. The xhtml export has the same error but I will write a follow up issue for this as the implementation is completly different.
I submitted issue 97866 to fix the xhtml export. Also changed the title of this issue to make the distinction clear. The output of the current html export is kind of dated. if anyone on the cc list likes to give me a hand to update it to current html feature set, please send me a mail.
verified in cws, back to qa
Verified in CWS.
Tested in OOO310_m2. Closed.