Created attachment 104282 [details]
File which demostrates problem
Step to produce:
In attached docx file has style named "Product Head" is not applied to first paragraph line . It is displayed in style list but not applied. It has before para property which is not in output. Probably something missing from import side.
Mac os 10.8
On Windows 7 sp1, 64-bit en-US with
Build ID: 62ad5818884a2fc2e5780dd45466868d4100
Document opens with the ProductHead style applied to the paragraph.
The style as applied shows as Verdana 22 point.
Also, please don't set your own reports as new. And, this issue was most certainly not critical.
Closing WFM, but if you still believe the style is not being correctly imported, go ahead and reopen with full details of what is missing from the style.
Actually going to set this to NEEDINFO,
seems there may be disconnect on import of the .docx and its styles. If I modify the "Product Head" Style as imported--it shows as Times New Roman, Bold, 21pt with condensed spacing and pair kerning. If I select and "Clear direct formatting" the paragraph assumes attributes for the "Product Head" style.
So question is why with the import filter, additional direct formatting is being applied over the style specified?
@Mahesh, please verify the attributes of your "Product Head" style.
(In reply to comment #1)
> On Windows 7 sp1, 64-bit en-US with
> Version: 220.127.116.11
> Build ID: 62ad5818884a2fc2e5780dd45466868d4100
> Document opens with the ProductHead style applied to the paragraph.
> The style as applied shows as Verdana 22 point.
> Also, please don't set your own reports as new. And, this issue was most
> certainly not critical.
> Closing WFM, but if you still believe the style is not being correctly
> imported, go ahead and reopen with full details of what is missing from the
Style ProductHead contains Times new Roman font with font size 21 point bold condensed by 2 point, kerning at 36 point, left indent 0.63 cm, line spacing 22 point exact, before para spacing 12 point
In text line "Rich Text Format (RTF) Specification" 12 point para spacing (Above para property in UI) is not applied.
Created attachment 104432 [details]
Anyone can see this document in Microsoft word and libreoffice. Difference is visible. Before para property is missing from base style ProductHead. This is very critical issue if you are using styles.
Setting NEW, issue would appear to be with the import filter(s) appending additional formatting to already styled .docx document.
@Mahesh, please confirm that the source program for both attached OOXML documents is MS Office for Mac 2011. Also, please confirm that following import filter opening with LibreOffice > 4.3.0 that a selection of the paragraph content with "Product Head" and applying the context menu "Clear Direct Formatting" reverts paragraph to correctly rendered style.
Finaly, what affect to a copy of the entire source document imported into LibreOffice if you "Select All" for the whole document and similarly apply "Clear Direct Formatting"?
Product head is based style and direct formatting is just override some properties not all properties. So it clear direct formatting is not going work. The document attached is modified in MS Office for Mac 2011. But document is RTF specification 2009 created by Microsoft.
Created attachment 137337 [details]
A.pdf: export from Word 2013 on Windows
Based on the document in the description, what I see in LO 3.6 thru 6.0alpha1 looks the same as what I see in MS Office 2013 on Windows 7 32bit.
Created attachment 137338 [details]
A new.pdf: export from Word 2013 on Windows
Based on the document in comment 4, I again don't see any different in LO compared to what I see in MSO 2013. In both cases, there is NO indent (until the style is re-applied overtop of the custom formatting).
Unless I am not understanding the problem, it sounds like a Mac Office incompatibility, and thus NotOurBug.
** 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 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!
Created attachment 160992 [details]
Screnshot of the document in Writer 6.1 and Writer 6.2dev
This 150pt Spacing before problem got solved in:
author László Németh <email@example.com> 2018-07-17 19:46:22 +0200
committer László Németh <firstname.lastname@example.org> 2018-07-18 08:55:01 +0200
tdf#118521 DOCX import: fix paragraph margin from paragraph style
*** This bug has been marked as a duplicate of bug 118521 ***