"Clear formatting" on a heading, at least, clears the RTL direction that I before. It shouldn't happen. Direction is not formatting. It is part of the content, itself.
Confirmed with 3.4.3.
I can't reproduce that in master, "Clear Direct Formatting" neither affects direction or text alignment setting.
I didn't test master, but it's not the case for 3.5.0 branch. Adding a little example/test case.
Created attachment 54376 [details] an example/test case
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Still the case in 3.5.0 beta2. Change status to NEW.
I can't reproduce this on LibreOffice 3.6.3.2
I can reproduce with version 3.6.4.1 (Build ID: a9a0717) on Debian 64bit
oh, OK i can reproduce this if your locale setting are not RTL Language. it clear the direction; depends on the locale setting. is this a bug?
I can reproduce it with both English locate/interface and with LC_ALL=he_IL.UTF-8 locale... Also, it both cases the directionality after clearing is RTL.
navin patidar committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bb920862c02047471f0ac5e78358e8d8fd9b93e7 fix fdo#40496: don't reset RES_PARATR_ADJUST & RES_FRAMEDIR attributes. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks! I love it when you fix bugs I report :) Feels great and I'm so greatful!
Fix verified on a build from master. Notice the bug talks about not clearing directionality but the fix also keeps alignment. I'm not sure if that's the wanted behavior for us or not.
(In reply to comment #13) > Fix verified on a build from master. > > Notice the bug talks about not clearing directionality but the fix also > keeps alignment. I'm not sure if that's the wanted behavior for us or not. Hi kaplan, It is necessary to keep alignment, otherwise RTL text will be left align when user applies clear formatting. "left align" is a default alignment doesn't matter writing direction is RTL or LTR, in case of clear formatting.
(In reply to comment #14) > It is necessary to keep alignment, otherwise RTL text will be left align > when user applies clear formatting. I don't agree here, as we should clear the alignment as requested. Think of cases where the alignment is center/justify which after the patch wouldn't be cleared (both LTR and RTL text).
(In reply to comment #15) > (In reply to comment #14) > > It is necessary to keep alignment, otherwise RTL text will be left align > > when user applies clear formatting. > > I don't agree here, as we should clear the alignment as requested. Think of > cases where the alignment is center/justify which after the patch wouldn't > be cleared (both LTR and RTL text). I agree, center/justify wouldn't be cleared. Is it acceptable to have RTL text align left ?? or we should choose default alignment based on writing direction. LTR text -> left alignment RTL text -> right alignment
(In reply to comment #16) > I agree, center/justify wouldn't be cleared. So that's a regression we introduced, mainly for LTR users. Can we agree on fixing this while we discuss the other part over ? > Is it acceptable to have RTL text align left ?? > or > we should choose default alignment based on writing direction. That's a good question, but should be discussed publicly (UI list or the dev list), but not here.
(In reply to comment #17) > So that's a regression we introduced, mainly for LTR users. Can we agree on > fixing this while we discuss the other part over ? > > Is it acceptable to have RTL text align left ?? > > or > > we should choose default alignment based on writing direction. > > That's a good question, but should be discussed publicly (UI list or the dev > list), but not here. I noticed in writer and impress that when writing direction is changed to RTL from LTR, alignment is also changed to right from left. that's why my opinion is to choose default alignment based on writing direction, but i'm not a RTL user. regression + correct default alignment issue can be fixed in a single patch.
(In reply to comment #18) > regression + correct default alignment issue can be fixed in a single patch. The regression fix is immediate, while the other needs public discussion and tests for the patch (See similar regression we got at bug 58919).
plz review https://gerrit.libreoffice.org/3182
navin patidar committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d0cfbb882c4c00fea4858f9d4b2511df66dd087b fix fdo#40496: don't reset RES_FRAMEDIR attribute. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks. This is even better :)
This should absolutely not have happened. Paragraph direction _is_ formatting - in ODF and in LO as an application. If anyone wanted to make an argument for the opposite - they should have made that argument rather than asking for changing a single aspect of behavior. And if direction were not formatting, we should not have been able to set RTL direction in named paragraph styles, nor in DF.
(In reply to Eyal Rozenberg from comment #23) > This should absolutely not have happened. > > Paragraph direction _is_ formatting - in ODF and in LO as an application. It might be the case in ODF and LO, but that is an implementation detail. Strictly speaking, paragraph direction is part of the text semantics and clearing formatting should not reset it. That is why in HTML, for instance, text direction is an element attribute, same as language. Even though CSS has direction property, authors are discouraged from using it (see the top warning in https://developer.mozilla.org/en-US/docs/Web/CSS/direction, for instance). > If anyone wanted to make an argument for the opposite - they should have > made that argument rather than asking for changing a single aspect of > behavior. And if direction were not formatting, we should not have been able > to set RTL direction in named paragraph styles, nor in DF. That is again an implementation detail, and indeed ODF and LO are incorrect in making paragraph direction a formatting attribute. That shouldn’t prevent us from at least improving the UX without having to re-write the internals of PDF and LO, and the change here was a net positive change.