Bug Hunting Session
Bug 82348 - FILEOPEN: DOCX IMPORT: style is being corrupted by direct formatting
Summary: FILEOPEN: DOCX IMPORT: style is being corrupted by direct formatting
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: Other All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx
Depends on:
Blocks: DOCX-Styles
  Show dependency treegraph
 
Reported: 2014-08-08 13:09 UTC by mahesh patil
Modified: 2019-02-15 03:46 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
File which demostrates problem (36.21 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2014-08-08 13:09 UTC, mahesh patil
Details
Style missing (46.10 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2014-08-11 11:25 UTC, mahesh patil
Details
A.pdf: export from Word 2013 on Windows (26.28 KB, application/pdf)
2017-10-28 12:06 UTC, Justin L
Details
A new.pdf: export from Word 2013 on Windows (26.28 KB, application/pdf)
2017-10-28 12:09 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mahesh patil 2014-08-08 13:09:31 UTC
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.

Operating system
Mac os 10.8
Windows 8
Comment 1 V Stuart Foote 2014-08-10 16:24:18 UTC
On Windows 7 sp1, 64-bit en-US with
Version: 4.3.0.4
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.
Comment 2 V Stuart Foote 2014-08-10 16:40:19 UTC
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.
Comment 3 mahesh patil 2014-08-11 11:22:02 UTC
(In reply to comment #1)
> On Windows 7 sp1, 64-bit en-US with
> Version: 4.3.0.4
> 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.

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.
Comment 4 mahesh patil 2014-08-11 11:25:21 UTC
Created attachment 104432 [details]
Style missing

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.
Comment 5 V Stuart Foote 2014-08-11 13:31:18 UTC
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"?
Comment 6 mahesh patil 2014-08-11 14:20:37 UTC
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.
Comment 7 Justin L 2017-10-28 12:06:07 UTC
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.
Comment 8 Justin L 2017-10-28 12:09:18 UTC
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.
Comment 9 QA Administrators 2019-02-15 03:46:48 UTC
** 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!

Warm Regards,
QA Team

MassPing-UntouchedBug