Bug 155268 - FILEOPEN DOC: anchors are considered whitespace - their direct formatting char size must not impact an empty paragraph
Summary: FILEOPEN DOC: anchors are considered whitespace - their direct formatting cha...
Status: RESOLVED DUPLICATE of bug 137335
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
Depends on:
Blocks: DOC-Paragraph
  Show dependency treegraph
 
Reported: 2023-05-12 22:29 UTC by Hossein
Modified: 2023-05-25 11:22 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
PDF Output created with the latest LO 7.6 dev on Windows (48.78 KB, application/pdf)
2023-05-12 22:29 UTC, Hossein
Details
PDF Output created with Office Live (8.32 KB, application/pdf)
2023-05-12 22:30 UTC, Hossein
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hossein 2023-05-12 22:29:47 UTC
Created attachment 187234 [details]
PDF Output created with the latest LO 7.6 dev on Windows

Description:
The paragraph spacing for the .doc files are sometimes incorrect.

Steps to Reproduce:
1. Open attachment 149081 [details] from tdf#123321 in LibreOffice
2. Create PDF output
3. Compare it with the output from MS Word. You can create PDF output with MS Office live viewer: (Click on "Print", then "Open PDF")
https://view.officeapps.live.com/op/view.aspx?src=https://bugs.documentfoundation.org/attachment.cgi?id=149081

Actual Results:
The paragraph spacing is different from MS Word, even on Windows with the same fonts

Expected Results:
The paragraph spacing should be similar to MS Word when appropriate fonts are availble


Reproducible: Always


User Profile Reset: No


Additional Info:

Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: a9c14a3b2c1d14373b63cf0aff0eb92ab5d640d8
CPU threads: 32; OS: Windows 10.0 Build 19044; UI render: default; VCL: win
Locale: en-US (en_DE); UI: en-US
Calc: threaded
Comment 1 Hossein 2023-05-12 22:30:30 UTC
Created attachment 187235 [details]
PDF Output created with Office Live
Comment 2 Buovjaga 2023-05-16 16:49:00 UTC
Please explain the exact thing we should be looking at.

I see that the office.com PDF output has incorrectly placed "Nnnnn nnnn" and "Nnnn nnnnn" to the right. I checked in office.com and it indeed places them in a different way compared to LibreOffice. So which one is the correct way?
Comment 3 Hossein 2023-05-16 17:13:02 UTC
(In reply to Buovjaga from comment #2)
> Please explain the exact thing we should be looking at.
> 
> I see that the office.com PDF output has incorrectly placed "Nnnnn nnnn" and
> "Nnnn nnnnn" to the right. I checked in office.com and it indeed places them
> in a different way compared to LibreOffice. So which one is the correct way?
I have not tested the placement of objects in Office Live, and I have seen that Office Live shows the things differently while editing in web browser. For example, justified text is displayed differently. That might be because of the limitations in web content, but this difference is not what I intended.

What I intended to say is that the paragraph spacing for the .doc file is clearly different in LibreOffice output compared to what MS Word generates in its output, and this should be considered a bug. If you compare the two PDF files side by side, the difference is clear.

I have changed the title, hoping that it is more clear now.
Comment 4 Hossein 2023-05-16 17:28:27 UTC
One thing to add is that while I have not tested editing the .doc file with Office Live, I did create the PDF output with the Office Live viewer, and also MS Word, and these two are almost the same.

https://view.officeapps.live.com/op/view.aspx?src=https://bugs.documentfoundation.org/attachment.cgi?id=149081
Comment 5 Buovjaga 2023-05-16 17:29:57 UTC
Ok, I will help you:

Pay attention to the text below the grey oval at the top. In the LibreOffice exported PDF, it is closer to the oval that in the MSO exported one.

Arch Linux 64-bit, X11
Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 41d96a72fc0e0a9fa35b6ac88a389473f8baedaf
CPU threads: 8; OS: Linux 6.3; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 16 May 2023
Comment 6 Justin L 2023-05-25 11:22:07 UTC
Identical in OOo 3.3.
The shape is irrelevant here. It is "wrap through". The placement of the text is strictly based on the number of carriage returns and their size.

If you turn on show formatting marks, in MS Word 2010 you will see that the first three blank paragraphs (which seem to be anchor points for the shape) are size 14, while the remaining CRs are size 10.

In LO, they are all size 10.

Hmm. I was going to mark as duplicate of DOCX bug 127368, but actually the size 14 is the "no direct formatting" size, and size 10 is the "direct formatting applied" size.

So this is actually a duplicate of DOCX bug 137335. The anchors must be considered "whitespace" and so the direct formatting of size 10 MUST NOT define the paragraph size when there is no other non-whitespace content.

*** This bug has been marked as a duplicate of bug 137335 ***