Bug 842568 - Bad spacing in Liberation Mono with BCI-hinting
Summary: Bad spacing in Liberation Mono with BCI-hinting
Alias: None
Product: Fedora
Classification: Fedora
Component: liberation-fonts
Version: 19
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Pravin Satpute
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2012-07-24 09:08 UTC by Markus
Modified: 2015-02-18 13:44 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-02-18 13:44:56 UTC
Type: Bug

Attachments (Terms of Use)
Spacing of "s" (14.17 KB, image/png)
2012-07-24 09:08 UTC, Markus
no flags Details
Merging of "ow" (1.24 KB, image/png)
2012-07-24 09:09 UTC, Markus
no flags Details
Same config, without changes (11.99 KB, image/png)
2012-07-30 16:07 UTC, Markus
no flags Details
Same config, with changes (12.70 KB, image/png)
2012-07-30 16:07 UTC, Markus
no flags Details
screenshot of "users download" with Liberation Mono font (76.57 KB, image/png)
2012-09-12 12:08 UTC, Pravin Satpute
no flags Details
In reality there is no space between '200' and 'W' but it's rendered like with a space (10.79 KB, image/png)
2012-09-19 18:40 UTC, Arkadiusz Miskiewicz
no flags Details
mono font - some letters are covering other letters (10.52 KB, image/png)
2012-09-19 18:41 UTC, Arkadiusz Miskiewicz
no flags Details
mail viewed in kmail1 (1.57 KB, text/plain)
2012-09-20 06:25 UTC, Arkadiusz Miskiewicz
no flags Details
screenshot of mentioned strings in Fedora 18 (38.10 KB, image/png)
2012-10-05 05:31 UTC, Pravin Satpute
no flags Details

Description Markus 2012-07-24 09:08:16 UTC
Created attachment 599962 [details]
Spacing of "s"

Description of problem:

Applies to Liberation Mono with BCI-hinting.

"s" is too far to the right or left, depending on the font size. E.g. "users" looks like "user s" at size 11. (See first attachment for font sizes 8-16.)

"ow" is merging in bold font, at least at size 11. E.g. in "downloads". (See second attachment.)

Version-Release number of selected component:

How reproducible:

Always with this ".fonts.conf":

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
	<match target="font">
		<edit name="antialias" mode="assign">
	<match target="font">
		<edit name="hinting" mode="assign">
	<match target="font">
		<edit name="hintstyle" mode="assign">
	<match target="font">
		<edit name="rgba" mode="assign">
	<match target="font">
		<edit mode="assign" name="lcdfilter">

With auto-hinting enabled instead, these problems do not occur:

	<match target="pattern" name="family">
		<test name="family" qual="any">
			<string>Liberation Mono</string>
		<edit name="autohint" mode="assign">

Comment 1 Markus 2012-07-24 09:09:52 UTC
Created attachment 599966 [details]
Merging of "ow"

Comment 2 Pravin Satpute 2012-07-24 09:27:25 UTC

"ftstring  -r 96 -m users ppem 200 LiberationMono-Regular.ttf" gives me different results. i.e. when we enable auto-hinting i can see more space and with enabling glyph level hinting is gives proper results.

Comment 3 Akira TAGOH 2012-07-24 10:14:34 UTC
Looking at the gasp table, Liberation Mono seems not supposed to use:

 * the grid-fitting for <= 8 ppem
 * the anti-aliasing for 8 > x <= 17 ppem but with the grid-fitting

So how about enabling auto-hinting for the above size then?

<match target="font">
  <test name="family" ignore-blanks="true"><string>Liberation Mono</string></test>
  <edit name="autohint" mode="assign"><bool>false</bool></edit>
  <edit name="hinting" mode="assign"><bool>true</bool></edit>
<match target="font">
  <test name="family" ignore-blanks="true"><string>Liberation Mono</string></test>
  <test name="pixelsize" compare="less_eq"><double>17</double></test>
  <test name="pixelsize" compare="more"><double>8</double></test>
  <edit name="autohint" mode="assign"><bool>true</bool></edit>
  <edit name="hinting" mode="assign"><bool>false</bool></edit>

Comment 4 Pravin Satpute 2012-07-30 10:26:30 UTC
Thanks Tagoh for this configuration. :)

Markus, i have built liberation with this configuration in rawhide, does it helps?

Comment 5 Markus 2012-07-30 16:05:16 UTC
I no longer see any bad spacing using my posted fonts.conf with or without the configuration changes posted by Tagoh. Why that is, I really don't know as I can't think of any relevant changes I have consciously made since.

I, again, used LibreOffice which I restarted after changing fonts.conf to create two new screenshots.

Comment 6 Markus 2012-07-30 16:07:05 UTC
Created attachment 601305 [details]
Same config, without changes

Comment 7 Markus 2012-07-30 16:07:42 UTC
Created attachment 601307 [details]
Same config, with changes

Comment 8 Akira TAGOH 2012-07-31 01:43:21 UTC
Have you updated liberation-fonts packages perhaps? as Pravin said at comment#4, he seems updated the package with comment#3. I guess that explains why?

Comment 9 Markus 2012-07-31 07:48:07 UTC
Does not seem to be the case. I still have version 2.00.0 which I installed 2012-07-22.

Comment 10 Pravin Satpute 2012-07-31 10:27:38 UTC
ohh, surprising!!
please try once with update rpm as well, it has customized .conf file as said above.

Comment 11 Pravin Satpute 2012-09-12 12:08:12 UTC
Created attachment 612078 [details]
screenshot of "users download" with Liberation Mono font

Without applied patch in 2.00.0-1 for Liberation Mono fonts, "users" and "download" rendering correctly.

Comment 12 Arkadiusz Miskiewicz 2012-09-17 15:10:56 UTC
Under KDE konsole when writting bunch of "ddddddddd" I'm getting very bad spacing, too (with liberation 2.0; in latest 1.7 there is no such problem). Not sure if this is exactly the same issue though.

Comment 13 Pravin Satpute 2012-09-18 10:41:39 UTC
Can you try with  liberation-fonts-2.00.0-2.fc18  once?

Comment 14 Arkadiusz Miskiewicz 2012-09-19 18:40:34 UTC
Created attachment 614523 [details]
In reality there is no space between '200' and 'W' but it's rendered like with a space

I'm not using FC but tried fonts 2.00 with configs from liberation-fonts-2.00.0-2.fc18 and no longer see the problem with multiple "dddd" in konsole.

I also see different problems (serif and mono) in kmail1 and liberation here. See screenshots attached.

Comment 15 Arkadiusz Miskiewicz 2012-09-19 18:41:14 UTC
Created attachment 614524 [details]
mono font - some letters are covering other letters

Comment 16 Pravin Satpute 2012-09-20 05:59:22 UTC
This looks like problem of Kerning.
Can you provide steps to reproduce?

1. liberation fonts version
2. freetype version
3. application used version
4. Your locale

Comment 17 Arkadiusz Miskiewicz 2012-09-20 06:25:56 UTC
Created attachment 614743 [details]
mail viewed in kmail1

liberation fonts 2.00.0 (with the fontconfig config for it the same as in -2.fc18 package)

freetype 2.4.10

kmail1 from kde4-pim (yes, old, newer is unusable for me); viewing html mail (attached); changing size of mail window makes the bug appear in different forms (once it's almost ok, changing window to wide - it's visible again etc). Tried to reproduce the same with kwrite (from kde 4.9.1) or libreoffice but was unable to get buggy results.

locale pl_PL.UTF-8

Comment 18 Arkadiusz Miskiewicz 2012-09-21 06:44:02 UTC
Looks like this isn't strictly liberation problem. I'm able to reproduce in kmail1 with various different fonts (dejavu, google croscore, vera) when I set to use small font (size less than 11-12). If the liberation font size is 12 then there is no problem.

Comment 19 Arkadiusz Miskiewicz 2012-09-21 07:15:23 UTC
hinting style: none, slight - problem visible. hinting style: medium, full - no problem. Ouh.

Comment 20 Pravin Satpute 2012-09-24 06:56:12 UTC
moving to kdepim

Comment 21 Pravin Satpute 2012-09-24 08:32:23 UTC
Arkadiusz can you open another bug against kdepim?

Markus can you reproduce same with updated liberation-fonts?

Comment 22 Markus 2012-10-03 19:40:17 UTC
Pravin, you mean the "users download" spacing issues?

Still using 2.00.0 from my distribution's repositories and I'm not sure how I'd quickly be able to test the unreleased/patched version.

Comment 23 Pravin Satpute 2012-10-05 05:31:34 UTC
Created attachment 621936 [details]
screenshot of mentioned strings in Fedora 18


Comment 24 Fedora End Of Life 2013-04-03 19:41:20 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:

Comment 25 Fedora End Of Life 2015-01-09 21:59:36 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 26 Fedora End Of Life 2015-02-18 13:44:56 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.