Bug 72640 - RTL: numbering alignment issue with doc and docx files
Summary: RTL: numbering alignment issue with doc and docx files
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:doc, filter:docx
Depends on:
Blocks: DOCX-Bullet-Number-Outline-Lists DOC-Bullet-Number-Lists DOCX-RTL DOC-RTL
  Show dependency treegraph
 
Reported: 2013-12-12 12:18 UTC by saeed
Modified: 2024-08-19 13:12 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
numbering alignment issue (173.05 KB, image/png)
2013-12-12 12:18 UTC, saeed
Details
NumAlign.doc (2.53 MB, application/msword)
2013-12-13 06:48 UTC, saeed
Details
NumAlign.docx (2.83 MB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2013-12-13 06:56 UTC, saeed
Details
NumAlignCompare.png (189.76 KB, image/png)
2013-12-13 06:57 UTC, saeed
Details
NumAlignRTL.doc (1.13 MB, application/msword)
2013-12-13 08:05 UTC, saeed
Details
NumAlignRTL.docx (2.83 MB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2013-12-13 08:06 UTC, saeed
Details
Screenshot MSO2013 NumAlignRTL.docx numbering indents and spacing (19.74 KB, image/png)
2018-04-13 13:41 UTC, Buovjaga
Details
NumAlign new screenshot on new versions LO+WORD (223.92 KB, image/png)
2018-09-17 20:01 UTC, Idan Miara
Details
NumAlignRTL new screenshot on new versions LO+WORD (197.33 KB, image/png)
2018-09-17 20:01 UTC, Idan Miara
Details
Screenshot of the original document side by side in Word and Writer (62.59 KB, image/png)
2020-05-05 13:23 UTC, NISZ LibreOffice Team
Details
72640_lefNumberingAlign.docx: minimal, from-scratch example. (8.58 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2021-04-23 11:14 UTC, Justin L
Details
72640_lefNumberingAlign_msword2010.pdf: how it looks in MS Word 2010 (22.28 KB, application/pdf)
2024-07-15 12:24 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description saeed 2013-12-12 12:18:44 UTC
Created attachment 90663 [details]
numbering alignment issue

Numbering alignment is set to "left" by default and it makes some problems specially with RTL text styles. User has to fix it manually via: Styles and Formatting tab --> List Styles --> Modify --> "Position" tab --> "Numbering Alignment".
Please see the attachment.

Another issue is the numbering format changes from "1-1-1-" in MS Word to "1.1.1-" in Libre Office. I do not no whether the user can fix this issue manually or not.

Regards
Saeed
Comment 1 Jean-Baptiste Faure 2013-12-12 17:38:55 UTC
Please, could you attach a test document?

What is your OS ?

Best regards. JBF
Comment 2 saeed 2013-12-13 06:48:45 UTC
Created attachment 90695 [details]
NumAlign.doc
Comment 3 saeed 2013-12-13 06:56:15 UTC
Created attachment 90696 [details]
NumAlign.docx
Comment 4 saeed 2013-12-13 06:57:06 UTC
Created attachment 90697 [details]
NumAlignCompare.png
Comment 5 saeed 2013-12-13 06:58:02 UTC
OK. I have to update my comments. I use win 8 and MS word 2010 and LO 4.1.2.3. I did not test this on LO 4.3.0.0.alpha. Today I tested my files on the alpha version and this is the result:
I have two files with same content. one is saved in .doc and another is saved in .docx format using MS word 2010.
1. DOC file:
In LO some text numbering styles are aligned wrongly (such as heading 3 and heading 4 in the attached file: NumAlign.doc). All text has to be alignd to right. 
2. DOCX file:
When I open it in LO 4.3.0.0.alpha all the numbering alignments are set to left which is wrong. They should be all aligned to right. (please see NumAlign.docx)

The problem of displaying number seperators is still not resolved in the alpha version. The original files (both .doc and .docx) have numbers like "1-1-1-". In LO it is displayed as "1.1.1-".

Please see the attachments.

Thanks
Saeed
Comment 6 Jean-Baptiste Faure 2013-12-13 07:21:17 UTC
Why did you change the version number if you detected the problem in 4.1.2? This version number is intended to show the oldest version in which the bug has been found.

Best regards. JBF
Comment 7 Jean-Baptiste Faure 2013-12-13 07:29:30 UTC
I do not understand why you want write English from right to left? Is it only to show the problem you discovered? If you look in the status bar, LibreOffice says that your text is in English.
In order to be sure that the problem does not come from incompatible settings, could you attach a test document in a RTL language.

Best regards. JBF
Comment 8 saeed 2013-12-13 08:05:56 UTC
Created attachment 90702 [details]
NumAlignRTL.doc
Comment 9 saeed 2013-12-13 08:06:29 UTC
Created attachment 90703 [details]
NumAlignRTL.docx
Comment 10 saeed 2013-12-13 08:07:48 UTC
There is no difference between LTR and RTL languages in this issue. I have uploaded two new files that are written in a RTL language. The result is the same.
Please take a look at "NumAlignRTL.doc" and "NumAlignRTL.docx".
Changing the version was my mistake. This is the first time I'm working with bugzilla! Sorry for that...

Again thank you
Saeed
Comment 11 Faisal Menawer 2014-01-02 09:18:09 UTC Comment hidden (no-value)
Comment 12 Joel Madero 2015-05-02 15:41:42 UTC Comment hidden (obsolete)
Comment 13 Buovjaga 2015-06-20 13:37:31 UTC
Confirmed.

Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+
Build ID: 3ecef8cedb215e49237a11607197edc91639bfcd
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-19_23:16:58
Locale: fi-FI (fi_FI)
Comment 14 QA Administrators 2016-09-20 10:10:54 UTC Comment hidden (obsolete)
Comment 15 Omer Zak 2017-11-04 20:02:14 UTC
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)
Comment 16 Mark Hung 2018-04-08 13:15:18 UTC Comment hidden (no-value)
Comment 17 Buovjaga 2018-04-08 13:31:28 UTC
Actually comment 11 is wrong and the alignment issue is not fixed.

I still opened bug 116883 for the 1-1-1- thing.
Comment 18 Mark Hung 2018-04-09 14:44:29 UTC
(In reply to Buovjaga from comment #17)
> Actually comment 11 is wrong and the alignment issue is not fixed.
> 
> I still opened bug 116883 for the 1-1-1- thing.

Look into word/numbering.xml in files extracted from the docx,
You can find the definition of Heading1 ( search for Heading1 ):

      <w:pStyle w:val="Heading1"/>
      <w:lvlText w:val="فصل %1-"/>
      <w:lvlJc w:val="left"/>

Writer convert it to align to the start ( logical left ) of the preserved space. I suspect the problem is in indention instead of the alignment. Can anyone confirm the behavior in Word, has the document aligned to the start or the end, despite how it looks?
Comment 19 Buovjaga 2018-04-12 13:33:22 UTC
(In reply to Mark Hung from comment #18)
> Writer convert it to align to the start ( logical left ) of the preserved
> space. I suspect the problem is in indention instead of the alignment. Can
> anyone confirm the behavior in Word, has the document aligned to the start
> or the end, despite how it looks?

I checked the headings in both docx files and they are aligned to "margin" in MSO 2013.
Comment 20 Buovjaga 2018-04-13 13:41:34 UTC
Created attachment 141339 [details]
Screenshot MSO2013 NumAlignRTL.docx numbering indents and spacing

Ok, I discussed with Mark on IRC and I have been confused and this whole report is highly confusing what with the multiple things to look at and two formats.

Attached is a screenshot showing that the -1-1 numbering in NumAlignRTL.docx has hanging indentation. The value is different for different numbering entries.

The numbering and bullets under the -1-1 numbering also have hanging indentation. The difference is the alignment is "both" instead of "left".

The -1-1 numberings have 0 left and right indentation.
The lists below it have 0,63 cm left indentation (same as their hanging value).

I hope this helps. I don't have time for more now, but can do later, if needed.
Comment 21 Idan Miara 2018-09-17 19:58:38 UTC Comment hidden (obsolete)
Comment 22 Idan Miara 2018-09-17 20:01:32 UTC Comment hidden (obsolete)
Comment 23 Idan Miara 2018-09-17 20:01:49 UTC
Created attachment 144961 [details]
NumAlignRTL new screenshot on new versions LO+WORD
Comment 24 QA Administrators 2019-09-18 02:52:05 UTC Comment hidden (obsolete, spam)
Comment 25 NISZ LibreOffice Team 2020-05-05 13:23:02 UTC
Created attachment 160378 [details]
Screenshot of the original document side by side in Word and Writer

Looks better in:

Version: 7.0.0.0.alpha0+ (x64)
Build ID: 00db5933ded1884b2ac453552badae20fa943478
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; 
Locale: hu-HU (hu_HU); UI-Language: en-US
Calc: CL
Comment 26 Justin L 2021-04-23 10:58:05 UTC
There is a choice of "left" and "start".  But based on the results and a comment in the documentation, it sounds like "left" should always be interpreted as "start" (and LO doesn't have a "start" native property).

> The possible values (see below) for this attribute are always specified
> with left specifying justification relative to the leading edge of the
> paragraph, and therefore change semantic between right-to-left
> and left-to-right documents.

Hmm. We do treat them both the same on import...
case NS_ooxml::LN_CT_Lvl_lvlJc:
            case NS_ooxml::LN_Value_ST_Jc_left:
            case NS_ooxml::LN_Value_ST_Jc_start:
                nValue = text::HoriOrientation::LEFT;
                break;

So then this probably needs to be handled in layout (per paragraph). (I wonder what the LO specification says about this? I found 20.223.2 <style:list-level-properties> but it doesn't mention RTL.
> The defined values for the fo:text-align attribute are:
> • center: center of the list label is positioned at the alignment position.
> • end: interpreted as fo:text-align=”right”
> • justify: label is justified.
> • left: list label starts at the alignment position.
> • right: list label ends at the alignment position.
> • start: interpreted as fo:text-align=”left”.

ODF seems to be fairly clear that it ignores RTL for styles, because the paragraph style explicitly states "The values of start and end are interpreted according to the writing direction of the text", while in this case start/end are ignored and treated as left/right.

So that suggests this would need a compatibility flag and special layout handling.
Comment 27 Justin L 2021-04-23 11:14:46 UTC
Created attachment 171367 [details]
72640_lefNumberingAlign.docx: minimal, from-scratch example.
Comment 28 Justin L 2023-05-12 14:29:47 UTC
repro 7.6+
Comment 29 Eyal Rozenberg 2024-07-15 08:03:36 UTC
(In reply to Justin L from comment #28)
> repro 7.6+

* Can you provide reproduction instructions based on your new example document? * Can someone decide which attachments are still relevant and which aren't?
* The first comment also mentions the problem of addition of extra dots to the number. Is that valid? If so, shouldn't it be a separate bug?
Comment 30 Justin L 2024-07-15 12:24:18 UTC
Created attachment 195314 [details]
72640_lefNumberingAlign_msword2010.pdf: how it looks in MS Word 2010

repro 25.2+

(In reply to Eyal Rozenberg from comment #29)
> Can you provide reproduction instructions based on your new example?
1.) Open 72640_lefNumberingAlign.docx

> Can someone decide which attachments are still relevant?
I'm not sure why you are asking. Are you not able to reproduce the screenshot-ed results? They are all pretty much relevant AFAICS. Specifically comment 25 pretty clearly shows "RTL: numbering alignment issue" from OP's original file.

> The first comment also mentions the problem of addition of extra dots to
> the number. Is that valid? If so, shouldn't it be a separate bug?
extra dots? Are you perhaps referring to comment 17 (which was fixed in 7.0 as shown by comment 25).
Comment 31 Eyal Rozenberg 2024-07-15 13:20:42 UTC
(In reply to Justin L from comment #30)
> 1.) Open 72640_lefNumberingAlign.docx

That's a somewhat confusing document. The reproduction instructions should describe expected vs actual results. At any rate, it looks quite similar to the PDF you posted right after that file.

... ah, I think I get it now, but we should really have reproduction instructions.


> > Can someone decide which attachments are still relevant?
> I'm not sure why you are asking.

This bug has 10 attachments. You've provided a "minimal, from-scratch example"; so, do we need to other attachments?


> Are you not able to reproduce the screenshot-ed results?

Only partially.

> They are all pretty much relevant AFAICS.

I don't understand how. I see 5 document files and 7 screenshots, of unspecified versions of LibreOffice, and with some of them marked "new" (suggesting we should ignore the older ones)

> > The first comment also mentions the problem of addition of extra dots to
> > the number. Is that valid? If so, shouldn't it be a separate bug?
>
> extra dots? Are you perhaps referring to comment 17 (which was fixed in 7.0
> as shown by comment 25).

You're right, I misspoke, it's replacement of hyphens with dots, i.e. "1.1.1-" instead of "1-1-1-".

----

Bottom line: With your permission, I'm going to whittle down a couple of comments and the attachments here to leave us with what's still the buggy behavior at this point.