Summary: | FILESAVE: missing <w:spacing w:after="0" w:before="0"/> in new document.docx (and other MSO 2010 formats) | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Joachim Otahal <jou> |
Component: | Writer | Assignee: | Luboš Luňák <l.lunak> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | connie.deiss, jmadero.dev, jou, kleidt, l.lunak, mihhkel, rene.peinl, suokunlong, tobias.burnus |
Priority: | high | ||
Version: | 3.5.2 release | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.freedesktop.org/show_bug.cgi?id=51340 https://bugs.freedesktop.org/show_bug.cgi?id=76597 |
||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 107830, 65675 |
Description
Joachim Otahal
2012-04-05 12:14:06 UTC
The bug is essentially the same if you use .odt, it just does not manifest since the default paragraph spacing is 0.00. TEST1.odt\content.xml (reduced to the important difference): <office:automatic-styles> <style:style style:name="P1" style:family="paragraph" style:parent-style-name="Standard" style:master-page-name="Standard"> <style:paragraph-properties style:page-number="auto"/> </style:style> </office:automatic-styles> TEST6.odt\content.xml (new document, change spacing to 0.1 and back to 0.0): <office:automatic-styles> <style:style style:name="P1" style:family="paragraph" style:parent-style-name="Standard"> <style:paragraph-properties fo:margin-top="0cm" fo:margin-bottom="0cm"/> </style:style> <style:style style:name="P2" style:family="paragraph" style:parent-style-name="Standard" style:master-page-name="Standard"> <style:paragraph-properties fo:margin-top="0cm" fo:margin-bottom="0cm" style:page-number="auto"/> </style:style> </office:automatic-styles> It should always save those spacings. I guess other spacings are affected too, but they did not yet annoy me : ) Thanks for releasing 3.5.2 right after I submitted the bug report. However: The bug is still there, just tested. Reproduced on 3.6.3.2 Marking: New (Confirmed) Normal (Can prevent high quality/professional work) High (saving as .docx is pretty normal, adding an extra line after each paragraph is problematic. Furthermore, in some cases this may result in penalties for users such as if a user submits a paper that has a length limit and these extra lines push it over the limit. Thanks for reporting this one, sorry it took a few months to triage it! *** Bug 50092 has been marked as a duplicate of this bug. *** (In reply to comment #1) > I guess other spacings are affected too, but they did not yet annoy me : ) Based on my testing, this at least affected the "paragraph spacing" and "line spacing", see my comment at: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=50092#c6 (just copy my comment in bug 50092 to here below:) THE REASON: * Default style of LO Writer document is SINGLE LINE SPACE, and "0" for AFTER PARAGRAPH. * However, default style of MS Office 2010 is MULTIPLE LINE SPACE (1.15), and "10 points" AFTER PARAGRAPH, as described in this article: http://office.microsoft.com/en-us/word-help/adjust-the-line-spacing-between-text-or-paragraphs-HP010368776.aspx * When export as .docx, Writer did not set the "<w:spacing..." attributes in "/word/styles.xml", as it is treated as DEFAULT by Writer. Added to MAB4.2. Setting to HIGHEST, as "MAB = HIGHEST". *** Bug 51340 has been marked as a duplicate of this bug. *** As discussed in bug 51340, this also affects other MSO 2010 file formats (like pptx), so changing the title. *** Bug 53551 has been marked as a duplicate of this bug. *** *** Bug 75017 has been marked as a duplicate of this bug. *** Although the problem is certainly related, I don't see how bug 51340 is a duplicate to that since it is regarding PPT instead of Word and it is not about creating spacing for a new document, but reading the existing spacing correctly from an existing document. (In reply to comment #11) > Although the problem is certainly related, I don't see how bug 51340 is a > duplicate to that since it is regarding PPT instead of Word I changed the title of this bug to include other MSO formats. > and it is not about creating spacing for a new document, but reading the existing spacing correctly from an existing document. That is exactly the same issue: 1. IMPORT: When LibreOffice opens a MSO 2007/10/13 file, it should apply the correct PARAGRAPH SPACE and LINE HEIGHT, when para space and line height is NOT SET in the xml file: * PARAGRAPH SPACE: should be the same as MSO 2007/10/13 (for Word format, it's 1.15; for PPT, I dont know) * LINE HEIGHT: should be the same as MSO 2007/10/13 (for Word format, it's 10 points after each paragraph; for PPT, I dont know either, should look into the microsoft site.) 2. EXPORT: When LibreOffice save a file as MSO 2007/2010/2013 format, it should set the PARAGRAPH SPACE and LINE HEIGHT in the xml file. Doing this will avoid confusion between applications. When the above IMPORT issue is fixed, the EXPORT part is not necessary if users are using the newer versions of LO with the fix included. But we'd better also fix the EXPORT part because someone may open your file in an older LO version and see a different view. To see if your PPTX issue is a duplicate to this one, I have to see in the PPTX xml file if the line height is really not set (i.e., default value in MSO). (But I am not familier with the pptx style xml file, maybe someone can help?) If it's not set, then MSO opens it as 1.5 line height and LO opens as single line height --> same issue. Adding bug 51340 as see also instead. Does the problem persist with a recent version of LO? I cannot reproduce using the steps given. I can only reproduced using the .docx document from bug #50092, but saving the original file again using a current LO version no longer reproduces the problem. I tested for that issue with LO 4.2.2.1 today, and it looks fine to me. The problem does not appear any more. From my point of view "RESOLVED". Please make sure to test all cases that were merged to this bug. In my tests, bug 51340, which was merged against my advice with this one, is still not resolved. If your bugreport was closed incorrectly as a duplicate of this one, just reopen it. I'm closing this bugreport as the original problem no longer occurs. |