Bug 842568
| Summary: | Bad spacing in Liberation Mono with BCI-hinting | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Markus <xously> |
| Component: | liberation-fonts | Assignee: | Pravin Satpute <psatpute> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 19 | CC: | arekm, fonts-bugs, i18n-bugs, jreznik, kevin, ltinkl, petersen, psatpute, rdieter, rnovacek, smparrish, tagoh, than |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-02-18 13:44:56 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
Created attachment 599966 [details]
Merging of "ow"
"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. 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> <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> </match> Thanks Tagoh for this configuration. :) Markus, i have built liberation with this configuration in rawhide, does it helps? 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. Created attachment 601305 [details]
Same config, without changes
Created attachment 601307 [details]
Same config, with changes
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? Does not seem to be the case. I still have version 2.00.0 which I installed 2012-07-22. ohh, surprising!! please try once with update rpm as well, it has customized .conf file as said above. 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.
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. Can you try with liberation-fonts-2.00.0-2.fc18 once? 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.
Created attachment 614524 [details]
mono font - some letters are covering other letters
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 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 4.4.11.1 (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 3.6.1.2 but was unable to get buggy results.
locale pl_PL.UTF-8
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. hinting style: none, slight - problem visible. hinting style: medium, full - no problem. Ouh. moving to kdepim Arkadiusz can you open another bug against kdepim? Markus can you reproduce same with updated liberation-fonts? 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. Created attachment 621936 [details]
screenshot of mentioned strings in Fedora 18
liberation-mono-fonts-2.00.1-1.fc18.noarch
freetype-2.4.10-2.fc18.x86_64
libreoffice-3.6.1.2-2.fc18.x86_64
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: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19 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. 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 bug. Thank you for reporting this bug and we are sorry it could not be fixed. |
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: 2.00.0 How reproducible: Always with this ".fonts.conf": <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <match target="font"> <edit name="antialias" mode="assign"> <bool>true</bool> </edit> </match> <match target="font"> <edit name="hinting" mode="assign"> <bool>true</bool> </edit> </match> <match target="font"> <edit name="hintstyle" mode="assign"> <const>hintfull</const> </edit> </match> <match target="font"> <edit name="rgba" mode="assign"> <const>rgb</const> </edit> </match> <match target="font"> <edit mode="assign" name="lcdfilter"> <const>lcddefault</const> </edit> </match> </fontconfig> With auto-hinting enabled instead, these problems do not occur: <match target="pattern" name="family"> <test name="family" qual="any"> <string>Liberation Mono</string> </test> <edit name="autohint" mode="assign"> <bool>true</bool> </edit> </match>