Bug 95838 - Right text margin not justified
Summary: Right text margin not justified
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: Other macOS (All)
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2015-11-15 16:00 UTC by uwehob
Modified: 2015-11-23 12:30 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

right margin not justified (23.65 KB, application/vnd.oasis.opendocument.text)
2015-11-15 16:00 UTC, uwehob

Note You need to log in before you can comment on or make changes to this bug.
Description uwehob 2015-11-15 16:00:40 UTC
Created attachment 120560 [details]
right margin not justified


upon writing a 130page book I see occasional failures to justify the right text margin, i.e. text is sticking out 1/2 to 2 characters into the empty space. These characters are not visible in the ODT but clearly visible as PDF.

Bug occurs in OpenOffice, LibreOffice 4.4.6 and 5.0.1 (not more tested) and is better visible as PDF. Fonts tested were Courier, Garamond and Linux Libertine. With different fonts, bug occurs with different extent on different lines.

See attachment with smaller bug extent in Garamond but keen in Courier.
Comment 1 V Stuart Foote 2015-11-16 01:39:13 UTC

*** This bug has been marked as a duplicate of bug 88941 ***
Comment 2 Ben McGinnes 2015-11-16 13:09:38 UTC
Re-opening due to this comment on #88941:

--- Comment #67 from uwehob@gmail.com ---
You reply to my bug report 95838 that this is a duplicate of bug 88941. 88941,
however, concerns only PDF export. The bug I reported can be seen in LO during
text editing as words cut with an invisible right portion.

It is claimed that this bug has been corrected in LO 5.0, however, as I have
indicated, it is still there in LO 5.0.1


It does sound similar to the one we saw in the previous bug, but with definite discrepancies worth double-checking.

In fact, as one of the (many) people who confirmed LO 5 fixed the old bug and now testing a PDF export of the sample file included here, I can replicate the same symptoms; the lines are justified properly as ODT, but in PDF one or two dart over the right edge with the remainder justified.

Whereas the old bug was a case where justification was honoured in ODT, but completely ignored during export/transform to PDF.

The sample file is only 2 pages as well, so it's not the result of the other document being 130 pages (though if it is a book general performance can be improved by splitting that into separate files per chapter and then using a master document to string them together to convert to other formats).

I suspect this issue may be related to fonts and UTF-8 encoding since there are German specific glyphs in evidence in the sample document (unsurprising given it's written in German ... quite possibly a cut & paste from some kind of medical history (cancer given the mention of tumors and that last word, but anyway, my monolingual guess work on subject matter is a silly digression).  What's more important is the occasional too-long lines post-export has been confirmed and this definitely isn't the bug that plagued LO 4.4.x only with loss of justification in PDF exports.
Comment 3 Ben McGinnes 2015-11-16 13:35:10 UTC
Interesting; saving as docx shows one line being slightly shorter than previously.  Subsequently printing to PDF instead of exporting (i.e. Command + P and saving to PDF from the drop down menus rather than the LO-specific function) produces the same result with the slightly long lines.

So this is not an ODF issue and might not be a LO-specific thing.

Unfortunately Ant/FOP PDF conversions still don't work for me, but I can run it through pandoc inconjunction with either or both of LaTeX and/or Sphinx (Python Docutils).  If a CSS file to provide correct justification can be produced I can also test wkhtmltopdf, though it will change the font unless it is explicitly overridden in the CSS.  Anyway, if the symptoms can be replicated by way of a PDF conversion with no relation to LO at all then it will pretty much have to be a font and/or Unicode issue.

It may or may not benefit from adjusting the border margins.
Comment 4 Ben McGinnes 2015-11-16 14:56:58 UTC
Following assorted tests and multiple conversion methods (via various XML/XSLT types for the most part), it looks like the occasional long line is due to not adjusting proportionally to the glyphs in those lines.  This is due to the book_default using fixed line spacing.  Changing that to proportional at 100% does not immediately fix it, but those longer lines are then revealed in the ODT file as well as the PDF (i.e. they match in appearance).

You may need to adjust your template further to get what you want for your book, but it is clearly the attempt to force things too far in the current template that is producing the unexpected results here.

Closing as it is not a bug in LibreOffice (if you switch to Text Body or default and justify all the text it won't go over the end, but it may not be in the specified fonts from the book template without additional changes).
Comment 5 V Stuart Foote 2015-11-16 15:14:51 UTC
Yes agree this is not the issue of bug 88941 -- that is fixed (just not backported to the 4.4 builds).

Seems the sample document extracted from OPs book is not correctly formatted. Something is wrong with the first paragraph that has direct formatting applied. Differs from the custom "book_5f_default" style named "book-default" and assigned to the second paragraph and page.

Other ODF renderings also choke on first paragraph of this document archive.

Find that simply selecting and clearing the direct formatting reverts the paragraph to the "book-default" paragraph style.  Courier New or other monospace font direct formatting can be applied over "book-default", or another paragraph style derived from "book-default" can be defined and applied. Either case justification becomes correct. However, I do still need to verify that on an OS X install.

For OP, please verify correct application of paragraph styles, and remove errant direct formatting that seems to be the issue here. Should resolve when you correctly define and assign a paragraph style to the text rendered in Courier now.

Try that and let us know.
Comment 6 uwehob 2015-11-16 15:28:23 UTC
Hi Ben,

indeed "clear formatting" and than reformatting Garamond justified or Courier justified seems to alleviate the problem.

This text was initially formatted using iWork09-Pages and went via DOCX-format into Libreoffice due to bad hyphenation in Pages09. I never intentionally fixed spacing. Is there a way to "unfix spaces" anywhere in the menues ?

I am relieved that this is not an OSX problem and also that I can continue with the book. I will add a mention of LibreOffice at the end of the book if everything goes fine now.

Many thanks for your help.

Uwe Hobohm
Comment 7 Ben McGinnes 2015-11-17 19:11:11 UTC
Ah, migrating from one of Apple's pet iThings, that explains so much.

The quickest way tounfix content is to select all (Command + A, might be different in the German edition) and then right-click (Control + click if you stick with Apple's one mouse-button environment) and select "clear direct formatting".  With a larger document, though, you are betteroff editing a style to apply changes like this in order apply the change to all relevant content.  You can also create a new style which inherits from the original and makes minor changes if you want to experiment and need to change back later.

I highly recommend reading the Writer Guide, which includes a section on Styles and Formatting.  Not only does it address things like this, but it will provide very useful information about things you may have not considered or previously ruled out as not feasible.

The English guides are here:


Unfortunately I couldn't find German ones and the native German information on the wiki is limited.  What I could find is here:

Comment 8 Buovjaga 2015-11-23 12:30:46 UTC
Correcting status to NOTABUG.