[upstream] switching paragraph style changes character orientation

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
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
Manifesting document saved as ODT

The bug still manifests if we save attachment 79954 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.