Bug 117700 - .html to .odt conversion (headless) sets asymmetrical margins
Summary: .html to .odt conversion (headless) sets asymmetrical margins
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: (X)HTML-Export
  Show dependency tree / graph
 
Reported: 2018-05-19 03:33 UTC by [REDACTED]
Modified: 2023-05-11 15:02 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Attachments
index.html which produces strange page margins once converted to .odt (851 bytes, text/plain)
2018-05-19 03:34 UTC, [REDACTED] 		Details
PDF export from ODT (14.56 KB, application/pdf)
2018-06-15 18:02 UTC, Buovjaga 		Details
PDF export from ODT, no margins in body (14.56 KB, application/pdf)
2018-06-16 07:21 UTC, Buovjaga 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description [REDACTED] 2018-05-19 03:33:31 UTC 
Description:
.html to .odt conversion (headless) sets asymmetrical, strange page margins. I'm not sure where it gets those from, but the original index.html doesn't have them so it seems like a bug. I attached the index.html that triggers this.




Steps to Reproduce:
1. Download the attached index.html
2. Convert it:  soffice --convert-to odt 'index.html' --headless --outdir .
3. Open the resulting .odt file and observe asymmetrical page margins

Actual Results:  
weird small and asymmetrical margins (much larger on the left side than all others)

Expected Results:
symmetric margins, ideally the default page margins (since the HTML doesn't actually specify any special margins on the body or html elements)


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0
Comment 1 [REDACTED] 2018-05-19 03:34:13 UTC 
Created attachment 142197 [details]
index.html which produces strange page margins once converted to .odt
Comment 2 Buovjaga 2018-06-15 18:02:57 UTC 
Created attachment 142782 [details]
PDF export from ODT

Repro

Arch Linux 64-bit
Version: 6.2.0.0.alpha0+
Build ID: 0d2c5e0838906101e1fdea93b4a0c422690e331c
CPU threads: 8; OS: Linux 4.16; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded
Built on June 15th 2018
Comment 3 Buovjaga 2018-06-15 18:07:08 UTC 
(In reply to jonas from comment #0)
> Expected Results:
> symmetric margins, ideally the default page margins (since the HTML doesn't
> actually specify any special margins on the body or html elements)

I don't know why you say this as the body clearly has 50px margin for all 4 sides:
<body style="margin:50px">

Also tested with 3.3.0 and reproduced:
libo33 -headless -convert-to odt -outdir . 'index.html'
Comment 4 [REDACTED] 2018-06-16 05:21:38 UTC 
(In reply to Buovjaga from comment #3)
> I don't know why you say this

Was an oversight of mine. However, I just tested that if you remove the style="margin:50px", the same thing happens - so it doesn't seem to actually have any effect on this bug and the margins truly seem to be resulting from thin air.

While this may be a minor issue, it leaves me with no obvious possibility of generating a word document from simple formatted text that I don't manually need to edit afterwards (which breaks my automated workflow, I'm trying to export this from another software).

Therefore, I'd be very interested in workaround ideas, if anyone has any. Like, any approach to take simple formatted text with headings and bold stuff and get an .odt in an automated conversion. I could generate any sort of basic format to help with this as long as it's not a huge amount of work to implement...
Comment 5 Buovjaga 2018-06-16 07:21:06 UTC 
Created attachment 142788 [details]
PDF export from ODT, no margins in body

Chapter 1 and 2 do not have the left margin, if I remove the margin rule for body in the .html
Comment 6 [REDACTED] 2018-06-16 07:27:23 UTC 
Yea but the overall page margins are still very asymmetrical with less margin on the right side. It's not that obvious with this test file with no text line reaching the right border, but in any document with actual text it's painfully obvious...
Comment 7 [REDACTED] 2018-11-10 19:05:17 UTC 
For what it's worth, I moved to python-docx and I'm no longer using the HTML import since in its current shape, it just doesn't produce a very usable result without manual editing (which simply doesn't scale)
Comment 8 QA Administrators 2019-11-11 03:36:59 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2021-11-11 04:14:09 UTC 
Dear jonas,

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 https://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://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug