Bug 153338 - FILEOPEN DOC Wrong position of frame in header (should spill outside of page)
Summary: FILEOPEN DOC Wrong position of frame in header (should spill outside of page)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:doc
: 90353 (view as bug list)
Depends on:
Blocks: DOC-Frames
  Show dependency treegraph
 
Reported: 2023-02-03 04:50 UTC by Jorge Moraleda
Modified: 2023-05-26 17:57 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
doc file that causes the problem (anonymized so it can be made public) (42.50 KB, application/msword)
2023-02-03 04:50 UTC, Jorge Moraleda
Details
PDF exported from office.com (93.30 KB, application/pdf)
2023-03-27 10:50 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jorge Moraleda 2023-02-03 04:50:42 UTC
Created attachment 185076 [details]
doc file that causes the problem (anonymized so it can be made public)

Dear developers,

The attached doc file contains a frame in the header that is too wide for the position specified. So the frame goes beyond the right edge of the page (when opened in MS Word one can see this).

 When I convert the doc using libreoffice, the width of the frame is maintained but the position is changed (shifted left) so the frame's right edge fits just at the right edge of the page.

I assume this behavior is not really "a bug" but the result of forcing the frame to fit within the page. If libreoffice must indeed have all frames within the page, can the importer be configured to force frames inside the page by modifying the width/height of the frame rather than its position? 

In this document, the result of modifying the width rather than the position would be much more desirable (since the part of the frame that spills outside of the page does not have any visible information). I can imagine that changing the width (height) could produce better results not only in this case but in many others.

So can the importer be configured to preserve position rather than size? If not, this would be a feature request to enable manual configuration of whether to preserve position or size when forcing frames to fit inside a page . Of course an automatic heuristic that chooses between changing position and trimming size (or a combination of both) based on the fact that trimming white space that falls outside of the page is acceptable might be even better than a manual configuration switch.

Thank you for your contributions to the open source community!

------------
By the way I received the original document with the problem described from a customer. I have anonymized it by using a binary editor to replace actual words with xxxxx so it can be placed in the public domain without issue.

The issue may be present in versions of libreoffice earlier than the one reported, but this is the one I have access to. (I run libreoffice in linux debian bookworm installed from the package manager)
Comment 1 Buovjaga 2023-03-27 10:50:37 UTC
Created attachment 186243 [details]
PDF exported from office.com
Comment 2 Buovjaga 2023-03-27 10:56:13 UTC
Already in 3.5. Did some searches, but could not find a duplicate.

Arch Linux 64-bit, X11
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: a9ba09b66feec19206b0b7c6b70c6d905a6dbfe2
CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 27 March 2023
Comment 3 Justin L 2023-05-25 13:11:17 UTC
(In reply to Jorge Moraleda from comment #0)
> So can the importer be configured to preserve position rather than size?
This could be done by adding a compatibility flag to handle MS imports differently than native LO frames, similar to TAB_OVER_MARGIN.

But probably much better is to just import the way it does and let the human fix the poor design choices.
Comment 4 Justin L 2023-05-26 17:57:54 UTC
*** Bug 90353 has been marked as a duplicate of this bug. ***