Steps to reproduce: 1. Create new paragraph 2. Change paragraph direction to RTL 3. Change paragraph style to Heading 1 Current Behavior: The paragraph becomes a heading but switches back to LTR direction. Expected Behavior: The paragraph becomes a heading but stays RTL.
Created attachment 79954 [details] Downstream attachment
As per downstream report https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1093765 : 1) lsb_release -rd Description: Ubuntu 13.04 Release: 13.04 2) apt-cache policy libreoffice-writer libreoffice-writer: Installed: 1:4.0.2-0ubuntu1 Candidate: 1:4.0.2-0ubuntu1 Version table: *** 1:4.0.2-0ubuntu1 0 500 http://archive.ubuntu.com/ubuntu/ raring/main i386 Packages 100 /var/lib/dpkg/status 3) What is expected to happen in Writer via a terminal: cd ~/Desktop && wget https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1093765/+attachment/3688368/+files/test-bug1093765.doc && lowriter --nologo test-bug1093765.doc is select all -> change combo box Apply Style from Text Body to Heading 1 and the text style changes, preserving the character order. 4) What happens instead is: (Example text=) טקסט לדוגמה changes to: טקסט לדוגמה (=Example text) Microsoft Office Professional Plus 2010 Word Version 14.0.6023.1000 (32-bit) changes it to: =)טקסט לדוגמהExample text(
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1.2 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-03-03
(In reply to Inkbug from comment #0) > Steps to reproduce: > 1. Create new paragraph > 2. Change paragraph direction to RTL > 3. Change paragraph style to Heading 1 > > Current Behavior: > The paragraph becomes a heading but switches back to LTR direction. > > Expected Behavior: > The paragraph becomes a heading but stays RTL. Reproduced. Win 7 Pro 64-bit, LibO Version: 4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432 Locale: fi_FI
*** Bug 96859 has been marked as a duplicate of this bug. ***
Still happens in: Version: 5.4.2.2.0+ Build ID: 1:5.4.2-3~bpo9+1 CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: gtk2; Locale: en-US (en_US.utf8); Calc: group OS: Debian 64bit Stretch (Debian 9.2, with some backported packages)
(In reply to Inkbug from comment #0) > Steps to reproduce: > 1. Create new paragraph > 2. Change paragraph direction to RTL > 3. Change paragraph style to Heading 1 > > Current Behavior: > The paragraph becomes a heading but switches back to LTR direction. > > Expected Behavior: > The paragraph becomes a heading but stays RTL. Managed to reproduce it by following your instructions on the "Downstream attachment" file, but not on a new document. Lubuntu 18.04.1 32bit LibreOffice Version: 6.1.1.2 Build ID: 1:6.1.1~rc2-0ubuntu0.18.04.1~lo3 CPU threads: 1; OS: Linux 4.15; UI render: default; VCL: gtk2; Locale: he-IL (en_US.UTF-8); Calc: group threaded
Dear Inkbug, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 158272 [details] Manifesting document saved as ODT The bug still manifests if we save attachment 79954 [details] as an ODT rather than a DOC file.
I am: * ABLE to reproduce with the original attached DOC document. * UNABLE to reproduce on a plain new document. * ABLE to reproduce on the ODT version of the original attachment. LO Version: 6.4.0.3 Build ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8 CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: gtk3; Locale: he-IL (en_IL); UI-Language: en-US Now, looking at the saved ODT's XML, we see: <office:automatic-styles> <style:style style:name="P1" style:family="paragraph" style:parent-style-name="Text_20_body" style:list-style-name="WW8Num2" style:master-page-name="Standard"> <style:paragraph-properties fo:margin-top="0in" fo:margin-bottom="0.0835in" loext:contextual-spacing="false" fo:text-align="end" style:justify-single-word="false" style:page-number="auto" style:writing-mode="rl-tb" /> </style:style> I wonder... perhaps the combination of tags: fo:text-align="end" style:writing-mode="rl-tb" is the culprit? That is, perhaps it's treated differently, or scrapped, when LO switch styles, because it's expecting this information elsewhere? Just speculating.
Dear Inkbug, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
With build: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ad387d5b984c6666906505d25685065f710ed55d CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US I am able to reproduce even on a plain new document. But let me offer more robust reproduction instructions: 1. Create a new Writer document. 2. Set the Default Page Style to LTR. 3. Set the Default Paragraph Style to LTR. 4. Set the Heading 1 paragraph style to LTR. 5. Enter some text (e.g. "hello"). 6. Change paragraph direction to RTL 7. Set the paragraph style to Heading 1 The paragraph direction switches to LTR. However - I am now wondering whether the DF of text direction should really be maintained. When we switch paragraph style, the pre-vspace and post-vspace are reset to the style's defaults, as is the background color and the border. Perhaps the text direction should be reset as well? Reporter, please opine on this if you're still around - and asking other users as well.
Why do you expect attributes to be consistent when switching from one style to another? If your default paragraph uses a (directly applied) italic font style it will be removed when switching to any other style. We could turn this question around and ask what you expect when switching from one style to another. Meaning whether all or just the different attributes should be overwritten. Let's say the text is Text Body with the special attribute italic (whether set directly or via style modification doesn't matter). Switching to Heading 1 could mean you expect the font size larger and the bold weight to be applied - in addition to the italic weight. This does not solve the use case to explicitly switch off an attribute, eg. H1 in bold but H2 not. The issue is clearly NAB.
(In reply to Heiko Tietze from comment #13) > Why do you expect attributes to be consistent when switching from one style > to another? If your default paragraph uses a (directly applied) italic font > style it will be removed when switching to any other style. Heiko, that's not exactly true: Only if the _entire_ paragraph uses the italic font will it go away. If part of the paragraph is in italic and part of it isn't - that will be preserved through paragraph style change.
(In reply to Eyal Rozenberg from comment #14) > If part of the paragraph is in italic... ...it's not a formatting on the paragraph but at the characters. The Style Inspector shows nicely where the attribute of the selection comes from. For the topic being discussed here you could switch to indentation, background color, or associated list attributes. You want these settings to switch on/off depending on the chosen paragraph style.
Italic is a formatting, while text direction is not.
(In reply to Urmas from comment #16) > Italic is a formatting, while text direction is not. Both are attributes of the paragraph. Clearly NAB.
AFAIK, the original reporter's preference wasn't ever designed this way so this is an enhancement request. Also, nothing changed in: Version: 7.5.0.3 (AARCH64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 8; OS: Mac OS X 13.1; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Latest Office still behaves the same way as noted in https://bugs.documentfoundation.org/show_bug.cgi?id=58070#c2 : Microsoft Word for Microsoft 365 MSO (Version 2212 Build 16.0.15928.20278) 64-bit
The decision to make the text direction a formatting attribute is a LO's idiosyncrasy; the text never changes its direction, it is its immutable semantic property.
Bug 168537 and bug 40496 are related to this discussion. The issue is, users don't have a consistent mental model for how text direction should work. Sometimes, people expect text direction to be part of paragraph style, and are surprised when the software behaves inconsistently with that. Other times, people are annoyed because the software treats text direction as part of paragraph style, and wipes out their text direction choices. Sometimes, these are even the same people in different discussions. Currently, text direction is treated as a formatting attribute. It is presented this way in the user interface, and it's also how the software handles it under the hood. Absent any consensus, I recommend we try to live with the choices that have already been made: make the software behave consistently with direction as paragraph style/DF as it has been designed, and instead think of ways to guide users toward editing styles instead of this confusing DF.
Agree with Jonathan, and Heiko, and marking NAB. However (and perhaps to soften the blow): 1. In ODF documents, a (paragraph) style is not required to set all possible properties. It is possible to define a style with no direction (technically: no `style:writing-mode` proper; and it may also set the direction to 'inherit' from the superordinate object. While LibreOffice doesn't have UI for unsetting a style's direction, it could and should; and we do have UI for setting "inherit". So, if you edit your styles not to apply direction - then they won't, and your DF will work. 2. A bug is already on file regarding auto-detecting text direction: bug 162120. While that would not solve every use-case - it does make it easier to simply _not_ have to set the style explicitly yourself and for it to have a reasonable default via autodetection. 3. We are planning a discussion of text direction - extrinsic vs intrinsic, and these different bugs, next week on October 8th in the LibreOffice design meeting. You may be interested in attending that via jitsi: https://listarchives.libreoffice.org/global/design/2025/msg00089.html