Apache OpenOffice (AOO) Bugzilla – Issue 124905
Help Text isn't right-aligned, in Hebrew/Arabic languages
Last modified: 2017-05-20 10:35:21 UTC
Created attachment 83394 [details] Hebrew/Arabic Help content is written LTR, instead of RTL. Reading the help files in Hebrew is awkward, since the content pane (left) is written in LTR, even though the help is translated into Hebrew/Arabic. (See attachement)
Can you test with older versions? I assume this isn't a regression.
The help files are transformed into HTML files, and opened in the help viewer, which internally uses Writer/Web. It seems the language is added to the paragraph, but that's not enough for Writer/Web to turn the paragraph LTR. Do the following experiment: a) Select menu File - Open, and paste this address: https://www.openoffice.org/he/product/writer.html - The file is opened with Writer/Web - The paragraph language depends on the selection of Tools - Options... - Language Settings - Default languages for documents - CTL; in my case, the default was Hindi, so the paragraph language in OpenOffice is displayed as Hindi (this seems to be because there is no language information on that HTML page). b) Save this HTML page, and edit it, modify the <p> element, adding a lang="he" attribute. Import that page with OpenOffice Writer/Web. Now the paragraphs are in Hebrew, but still LTR c) Modify the HTML page again, now add the attribute dir="RTL" to all the <p> elements, they should all be <p lang="he" dir="RTL"> Import the page in OpenOffice Writer/Web. Now the paragraphs are in Hebrew *and* RTL.
The Online Help also uses a CSS to style the help pages, see http://svn.apache.org/viewvc/openoffice/trunk/main/helpcontent2/source/auxiliary/he/default.css?revision=1413471&view=markup On the installation, it would be /opt/openoffice4/help/he/default.css It would be ideal to localize that CSS files, because CSS2 supports the direction property; but a simple test shows that OpenOffice Writer/Web cannot handle it.
(In reply to Ariel Constenla-Haile from comment #3) > It would be ideal to localize that CSS files, because CSS2 supports the > direction property; but a simple test shows that OpenOffice Writer/Web > cannot handle it. See http://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#direction As a simple test, add <style type="text/css"> body, p, h1, h2, h3, h4, h5, h6 {direction:RTL; unicode-bidi:embed;} </style> to https://www.openoffice.org/he/product/writer.html and open it with Writer/Web: the text is still LTR.
(In reply to Ariel Constenla-Haile from comment #4) > (In reply to Ariel Constenla-Haile from comment #3) > > It would be ideal to localize that CSS files, because CSS2 supports the > > direction property; but a simple test shows that OpenOffice Writer/Web > > cannot handle it. > As a simple test, add <style type="text/css"> > body, p, h1, h2, h3, h4, h5, h6 {direction:RTL; unicode-bidi:embed;} > </style> to https://www.openoffice.org/he/product/writer.html and open it with > Writer/Web: the text is still LTR. Ariel, I understand that the help dialog uses the Writer/Web interpreter. Opening the webpage within Writer, I see the text direction is RTL, but LEFT-ALIGNED (changed issue's title). Maybe we can just add to the CSS "body{ ... direction: rtl; text-align: right;}" and that would solve this issue. I think Writer/Web supports text alignment, and the "direction" instruction can be there for future's sake, if that's not supported yet. How can we test my suggestion? to create a test webpage and open it with Writer, as you instructed me?
(In reply to Tal from comment #5) > Maybe we can just add to the CSS "body{ ... direction: rtl; text-align: > right;}" and that would solve this issue. > I think Writer/Web supports text alignment, and the "direction" instruction > can be there for future's sake, if that's not supported yet. > > How can we test my suggestion? to create a test webpage and open it with > Writer, as you instructed me? You can test directly with the CSS that comes in the installation (first close OpenOffice completely, including the quick starter; then do a backup). The file is located in opt/openoffice4/help/he/default.css (Linux) On Windows it will be in something like C:\Program Files (x86)\OpenOffice 4\help\he\default.css Edit that file, start OpenOffice, and see if the Online Help works as expected.
Created attachment 83414 [details] Fixed CSS for Hebrew & Arabic.
(In reply to Ariel Constenla-Haile from comment #6) > You can test directly with the CSS that comes in the installation (first > close OpenOffice completely, including the quick starter; then do a backup). > The file is located in [...] > > Edit that file, start OpenOffice, and see if the Online Help works as > expected. Thanks, Ariel, I think I've fixed it by changing the CSS (see prev. attachment#83414 [details]). Appended text-align & direction to 1st style in default.css: body, p, li, h1, h2, h3, h4, h5, h6, .listitem, .listitemintable, .tablecontent, .tablecontentintable { font-family: "Bitstream Vera Sans",Arial,Helvetica,Lucida,Geneva,Helmet,sans-serif,"Andale Sans UI","Arial Unicode MS","Lucida Sans Unicode",Tahoma; text-align:right; direction:rtl;} Thanks again for instructing me where to test it. I'll try to commit this change, Tal
Committed rev#1595617 to fix this issue for Hebrew & Arabic. Thanks again, Ariel. Can I mark this as Resolved?
(In reply to Tal from comment #9) > Thanks again, Ariel. > Can I mark this as Resolved? For the next time, please note that code should committed on the source code repository only if you tested that the code compiled and didn't break the build. Although a CSS file might not seem code, it is inside the source code repository, and a build should be done before committing the change; a change that might not look code-related, can indeed break the build, see issue 121825 and Revision 1452033. So the rule is that if the committer does not build OpenOffice her/himself, then she/he should attach the patch to the issue, and ask for revision. > Committed rev#1595617 to fix this issue for Hebrew & Arabic. There is a bot that posts a comment in bugzilla about the commit, if you follow the rule of starting the commit message with the bug number #NNN# iNNN #iNNN# see the commits on http://svn.apache.org/viewvc/openoffice/trunk/main/ that follow that pattern. You can leave it as is, or you can change the commit message, see http://subversion.apache.org/faq.html#change-log-msg
(In reply to Tal from comment #9) > Can I mark this as Resolved? You need to change the other CSS files located in the same folder in the source tree. Some are used automatically if your desktop theme is dark, OpenOffice turns to "high contrast mode"; but you can switch the style sheet manually with the Options dialog: Tools - Options..., OpenOffice - General - Help - Help formatting; there you'll see a listbox with the different style sheets.
(In reply to Ariel Constenla-Haile from comment #11) > You need to change the other CSS files located in the same folder in the > source tree. Some are used automatically if your desktop theme is dark, > OpenOffice turns to "high contrast mode"; but you can switch the style sheet > manually with the Options dialog: Tools - Options..., OpenOffice - General - > Help - Help formatting; [..] Got it, Ariel, I'll fix & send a patch, this time, for the other Help "themes".
Created attachment 83437 [details] Patch fixing Help CSS files for Hebrew & Arabic Patch CSS files were tested on my local 4.1 Release installation (Win 7). Attaching a patch, since I can't test after build OO on my machine.
(In reply to Tal from comment #13) > Created attachment 83437 [details] > Patch fixing Help CSS files for Hebrew & Arabic > > Patch CSS files were tested on my local 4.1 Release installation (Win 7). > Attaching a patch, since I can't test after build OO on my machine. The patch builds fine, please commit :) (recall to use on the commit message the pattern i124905 - <message>). Unrelated to this, I see a lot of broken tags, for example, search by title "Inserting Charts", the page starts with bookmark_value\>charts; inserting\</bookmark_value\> Is pootle in the same state as the Online Help?
"tal" committed SVN revision 1597166 into trunk: i124905 - Changed text alignment in Hebrew/Arabic Help CSS themes; Ariel Cons...
Fixed my first bug :)
Supplemental: Checking AOO 4.1.1 Snapshot M3, the bug isn't resolved since changes in trunk are not present in the /help folder, after installation (old default.css of Hebrew help files). Can anyone explain why this happens? is the Snapshot M3 built from different branch, and not from the trunk?
(In reply to Tal from comment #17) > Can anyone explain why this happens? is the Snapshot M3 built from different > branch, and not from the trunk? trunk is where daily development happens, the next release is based on a different branch of code, and code is merged from trunk to that branch *only* if approved by the release manager. You can see that your changes were applied to trunk, where you committed the code, not to the AOO410 branch: http://svn.apache.org/viewvc/openoffice/trunk/main/helpcontent2/source/auxiliary/he/default.css http://svn.apache.org/viewvc/openoffice/branches/AOO410/main/helpcontent2/source/auxiliary/he/default.css
grant showstopper flag
OK, thanks Ariel, Juergen, but I'm still confused: After committing code changes, do I need to notify someone to merge changes from trunk to the release branch? If so, who's the release manager? Juergen? Is that the purpose of the show stopper flag? to ask to merge changes from the release manager?
yes I am acting as release manager and yes the showstopper flag is an indicator that the fix or issue is relevant for AOO 4.1.1. "?" means the fix should be considered for the next release, "+" means the issue is accepted as showstopper. A ? does not mean that is automatically fixed in the release. In your case the issue has now the showstopper flag and can be merged from trunk into the branch. Does the revision 1597166 contain all necessary changes? If yes I will merge it.
(In reply to jsc from comment #21) Thanks for the clarification. Yes, revision 1597166 includes all necessary changes, and fixed this bug for Arabic & Hebrew Help systems, a few months ago.
"jsc" committed SVN revision 1614047 into branches/AOO410: #124905# merge fix from trunk, adapt text alignment
fix merged into AOO410 branch for AOO 4.1.1
Verified on RC1. Thanks.