Bug Hunting Session
Bug 82374 - Autohyphenation at 11pt in all fonts leaves no space between last character and hyphen
Summary: Autohyphenation at 11pt in all fonts leaves no space between last character a...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
Reported: 2014-08-09 00:02 UTC by hmcrooke
Modified: 2018-12-02 20:01 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Hyphenation when printed (4.65 KB, image/png)
2014-08-21 12:38 UTC, hans.schmidt.5
Hyphenation with PDF export (8.40 KB, image/png)
2014-08-21 12:39 UTC, hans.schmidt.5
Correct hyphenation (as it should be) (11.84 KB, image/png)
2014-08-21 12:39 UTC, hans.schmidt.5
hyphens printed with 600 dpi (1.76 MB, image/png)
2015-01-21 00:26 UTC, user_58
hyphens printed with 2400 dpi (1.89 MB, image/png)
2015-01-21 00:28 UTC, user_58
original ODT test file (37.64 KB, application/vnd.oasis.opendocument.text)
2015-01-21 11:44 UTC, user_58

Note You need to log in before you can comment on or make changes to this bug.
Description hmcrooke 2014-08-09 00:02:40 UTC
With all fonts, at 11pt., autohyphenation leaves no space between the last character in the line and the hyphen, which often touches or overlaps it.
Comment 1 Adolfo Jayme 2014-08-10 15:24:39 UTC
What operating system do you use? This may as well be just a rendering artifact, rather than an actual spacing error — does exporting to PDF render fine, for example?
Comment 2 hans.schmidt.5 2014-08-21 12:38:47 UTC
Created attachment 105037 [details]
Hyphenation when printed
Comment 3 hans.schmidt.5 2014-08-21 12:39:23 UTC
Created attachment 105038 [details]
Hyphenation with PDF export
Comment 4 hans.schmidt.5 2014-08-21 12:39:40 UTC
Created attachment 105039 [details]
Correct hyphenation (as it should be)
Comment 5 hans.schmidt.5 2014-08-21 12:40:54 UTC
I have the same problem.

Arch Linux, with Libreoffice The font is Calibri, 11 pt. German text language.

When printing directly from LibreOffice on a Kyocera Mita FS 1920, the hyphenation _always_ runs into the last letter. This makes direct printing from LibreOffice absolutely useless. On the other hand, when exporting a PDF, the spacing is not too narrow, but on the other hand slightly too large. This is still somewhat usable, but looks slightly weird.

I have attached three images which show the problem. Only the last one hyphenation-3-correct.png is correct. I have manually written the words in LO Writer like this:


It would be extremely good if this is fixed. Currently this makes LO close to unusable for serious usage at the moment.
Comment 6 hans.schmidt.5 2014-09-18 13:24:05 UTC
Is there any reaction to this bug report?

I have the slight suspicion that this issue arises because the font "OpenSymbol" is used, which does not go well with Calibri. I don't know why LibreOffice uses OpenSymbol, even if I use Calibri for the main font.
Comment 7 Jacques Guilleron 2014-09-18 21:32:46 UTC
Hi all,

I copied and Paste without issue:

with Calibri font 11 pts in LO
Build ID: 5aeb852efcabdd51545d5d41c92f4bf3cef1d663
TinderBox: Win-x86@39, Branch:master, Time: 2014-09-08_07:01:57
& Windows 7 Home Premium
Odt, Printing and Export to pdf show no difference.


Comment 8 a07cd040897db54e103c 2014-12-18 09:03:54 UTC
May be this is related to bug #76014. Then you should be able to workaround this problem by changing the the system default printer BEFORE LO START to another one.
Comment 9 tommy27 2015-01-04 15:19:09 UTC
Status NEW because of confirmation in comment 5
version set to and O/S to Linux

I'd like to know from affected user if they still experience this in LibO
Comment 10 user_58 2015-01-21 00:23:21 UTC
I can reproduce this bug in LibreOffice, and in the forthcoming version under Kubuntu 14.10 (64 bit). This bug is also reproducible under Knoppix 7.4.2 (Live-USB) and CentOS 7.0-1406 (Live-USB) with a Canon MG5350.

Today I have reinstalled my whole system and I have now a fresh formatted, clean Kubuntu 14.10 system. The bug is still reproducible.

Fortunately a workaround exists: When I change the printer language (in the printer dialogue) from the default setting "PDF" to "PostScript (driver level)", the text is been printed properly.

When I print text with 600 dpi, the hyphens overlapp with the text on the left. When I print with 2400 dpi resolution, the space between the hyphen and the text is IMHO too wide. The problem appears at manual hyphenation as well as at automatic hyphenation.

I have attached two PNG files.
Comment 11 user_58 2015-01-21 00:26:52 UTC
Created attachment 112575 [details]
hyphens printed with 600 dpi
Comment 12 user_58 2015-01-21 00:28:55 UTC
Created attachment 112576 [details]
hyphens printed with 2400 dpi
Comment 13 user_58 2015-01-21 11:44:28 UTC
Created attachment 112598 [details]
original ODT test file
Comment 14 Frank 2015-01-21 16:01:14 UTC
I can confirm this behavior in LibreOffice Writer on 64 bit Ubuntu 14.04. I have experienced it with fonts other than those mentioned, specifically with FreeSerif and its companions.

Because of other quirks with LibreOffice dual-sided printing, I always export to pdf and print from Acrobat Reader, so this isn't such a big deal for me, but I agree that it is annoying.
Comment 15 user_58 2015-05-20 22:18:15 UTC
This bug is still reproducible in Kubuntu 15.04 and LibreOffice

Therefore hyphenation is simply not usable with PDF as default printer language.

When I change the printer language (in the printer dialogue) from the default setting "PDF" to "PostScript (driver level)", the text is been printed properly.
Comment 16 QA Administrators 2016-09-20 09:42:33 UTC Comment hidden (obsolete)
Comment 17 user_58 2016-09-20 10:03:59 UTC
The bug is still present:

KDE neon User Edition 5.7 (based on Ubuntu 16.04)
Comment 18 Frank 2016-09-20 12:43:28 UTC
Using Version: on Ubuntu 16.04.1.

This bug is still present and, when printing directly from LibreOffice, appears on the printed page as well as the screen.

This isn't really an issue for me, however, since I seldom ever print directly from LibreOffice (way too many problems with that), and export to pdf for printing (which seems to work fine).

Has anyone experienced this issue on Windows? LO seems to rely on Linux to read font information and, whether due to ill-formed fonts or bugs in fontinfo, Linux provides unreliable information about the font. The only comment posted with this bug report that DOESN'T experience this is from a Windows user. (albeit from the statistically significant sample of six!!!)
Comment 19 Xisco Faulí 2017-09-29 08:53:29 UTC Comment hidden (obsolete)
Comment 20 Frank 2017-09-29 13:52:53 UTC
I happened to have just installed Linux Mint 18.2 on a new Intel machine that has LibreOffice as part of its default apps. Since I hadn't yet removed LO, I retested for this bug and can confirm that it is still present.

On another Ubuntu 16.04 AMD machine, I still had a LibreOfficeDev (later versions were all removed since LO has too many "issues" for my particular uses), so I fired that up and tested. I can confirm that this bug is still present on that combination as well (not surprising; Mint is an Ubuntu derivative).

As I mentioned in Comment 18, I really suspect this has to do with LO's use of Linux font information system calls (the same reason Writer does bizarre and inappropriate font substitutions without reporting them to the user).

Before (mostly) abandoning LO, I learned quite some time ago to never print from within Writer anyway - I mostly "printed" to pdf and then let Adobe Reader do the actual printing (indicating that the generated pdf is done properly, and that Adobe Reader has a way of getting font metrics on its own).

The steps for reproducing this bug are well documented - even in earlier postings on this bug tracker - so I'm rather fascinated by the notion that - because no one has complained about this for more than a year - it might have magically fixed itself and gone away. While I obviously can't speak for everyone, it is fairly clear that bugs only get worked on (much less actually fixed) when they're simple to fix; fair enough - it's free. It's also clear that not considering certain classes of bugs (like text rendering) "in toto" (rather than as individual quirks) insures that they'll probably never be fixed.
Comment 21 user_58 2018-12-02 19:58:05 UTC
Bug cannot be reproduced in LibreOffice Version Bug can be closed.