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
Please, could you attach a test document? What is your OS ? Best regards. JBF
Created attachment 90695 [details] NumAlign.doc
Created attachment 90696 [details] NumAlign.docx
Created attachment 90697 [details] NumAlignCompare.png
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
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
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
Created attachment 90702 [details] NumAlignRTL.doc
Created attachment 90703 [details] NumAlignRTL.docx
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
the alignment are fix in Bug 43093. still there issue the numbering format changes from "1-1-1-" in MS Word to "1.1.1-". confirmed using libreoffice Version: 4.3.0.0.alpha0+ Build ID: 0dce3178fa75ad1d6f663ccd6548a1c54c6a93bd change the status to new
** 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.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) 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-05-02
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)
** 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 (5.1.5 or 5.2.1 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) 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
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)
Hi, If alignment issue has been fixed ( per comment #11 ), can this issue be closed? The numbering format changing from "1-1-1-" in MS Word to "1.1.1-" is LibreOffice's limitation displaying multiple level of numbering. It's not RTL specific, not doc or docx specific, and should deserve its own bug number.
Actually comment 11 is wrong and the alignment issue is not fixed. I still opened bug 116883 for the 1-1-1- thing.
(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?
(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.
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.
The problem of displaying number seperators is still not resolved in 6.1.1.2 on Windows. The original files (both .doc and .docx) have numbers like "1-1-1-". In LO it is displayed as "1.1.1-". I didn't understand the first issue, but I'm attaching a new screenshot with recent versions of MS Office and LO with these docs opened.
Created attachment 144960 [details] NumAlign new screenshot on new versions LO+WORD The problem of displaying number seperators is still not resolved in 6.1.1.2 on Windows. The original files (both .doc and .docx) have numbers like "1-1-1-". In LO it is displayed as "1.1.1-". I didn't understand the first issue, but I'm attaching a new screenshot with recent versions of MS Office and LO with these docs opened.
Created attachment 144961 [details] NumAlignRTL new screenshot on new versions LO+WORD
Dear saeed, 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 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
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.
Created attachment 171367 [details] 72640_lefNumberingAlign.docx: minimal, from-scratch example.
repro 7.6+
(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?
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).
(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.