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.