Bug 146957 - Header text (w:ptab ) and page number (framePr in BlockSDT) in footer are inconsistent in for .docx files
Summary: Header text (w:ptab ) and page number (framePr in BlockSDT) in footer are inc...
Status: RESOLVED DUPLICATE of bug 78144
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx
: 146956 (view as bug list)
Depends on:
Blocks: DOCX-Header-Footer DOCX-Content_Control
  Show dependency treegraph
 
Reported: 2022-01-24 09:49 UTC by Luis Capuyon
Modified: 2023-05-18 15:40 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Sample document for the bug report (102.74 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2022-01-24 09:50 UTC, Luis Capuyon
Details
Shows the actual result (367.42 KB, image/png)
2022-01-24 09:50 UTC, Luis Capuyon
Details
Shows the expected result (153.72 KB, image/png)
2022-01-24 09:51 UTC, Luis Capuyon
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luis Capuyon 2022-01-24 09:49:19 UTC
Description:
When opening a .docx file with LibreOffice with header text and page number texts, the format of the header text and the position of the page number is not consistent compared to when it is opened in MS Office.




Steps to Reproduce:
1.Open the attached file.
2. Navigate to the second page.

Actual Results:
- The header text shown in LibreOffice is not correctly centered. It seems that the header text does not take the whole space of the page.
- The page number is positioned at the lower left corner of the page.

Expected Results:
- The header text should be correctly centered and take up the entire width of the page.
- The page number should be positioned at the lower right corner of the page.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.2.4.1 / LibreOffice Community
Build ID: 27d75539669ac387bb498e35313b970b7fe9c4f9
CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx
Locale: en-PH (en_PH.UTF-8); UI: en-US
Calc: threaded
Comment 1 Luis Capuyon 2022-01-24 09:50:32 UTC
Created attachment 177736 [details]
Sample document for the bug report
Comment 2 Luis Capuyon 2022-01-24 09:50:57 UTC
Created attachment 177737 [details]
Shows the actual result
Comment 3 Luis Capuyon 2022-01-24 09:51:18 UTC
Created attachment 177738 [details]
Shows the expected result
Comment 4 raal 2022-01-24 15:56:52 UTC
*** Bug 146956 has been marked as a duplicate of this bug. ***
Comment 5 eisa01 2022-02-06 12:09:40 UTC
I can confirm

Likely not a macOS issue, so setting OS to all, until proven otherwise :)

Version: 7.3.0.3 / LibreOffice Community
Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
CPU threads: 10; OS: Mac OS X 12.2; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 6 Justin L 2022-09-06 12:03:07 UTC
repro 7.5+ with linux.  (It doesn't look right in MS Word 2003 either).

The first page style (portrait) looks fine, but the second page style (landscape) uses the same tabstops as the first page.

Also confirming the page number on the left instead of the right. (Is that in a frame in modern MS Word?)

This is a "new page section break" and not a "continuous section break" so we should be able to handle this one fine.
Comment 7 Stéphane Guillou (stragu) 2022-12-03 23:14:00 UTC
Already an issue in:

Version: 6.1.6.3
Build ID: 5896ab1714085361c45cf540f76f60673dd96a72
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk2; 
Locale: en-AU (en_AU.UTF-8); Calc: group threaded
Comment 8 Justin L 2023-05-18 15:40:21 UTC
repro 7.6+
This one is rather strange. Of course, it is also very strangely designed.
So the page number at the bottom makes sense. We simply don't import blockSDTs as SDTs, so everything in here will be messed up. (Why put it in a content control???). That is why the framePr is being ignored. [There are lots of bug reports about blockSDT not being handled, like bug 148035. Ignore for this bug report.]


The header is a problem. It seems to be a relatively new feature of MS Office - a centered tab in whatever context. LO doesn't have anything comparable. I'll mark this as a duplicate of bug 78144.

The header has a "character run" like this
<w:r>
  <w:ptab w:relativeTo="margin" w:alignment="center" w:leader="none"/>
</w:r>

// We only handle the case when the line already has content, so the left-aligned ptab is
    // equivalent to a line break.
    if (nAlignment != NS_ooxml::LN_Value_ST_PTabAlignment_left)
        return;

w:ptab initial support in commit 8bac48991857d222f0e8f0c07b8c4e06649e1632
Author: Miklos Vajna on Fri Jan 28 13:38:20 2022 +0100
    DOCX import: handle a subset of <w:ptab w:alignment="left">

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