Red Hat Bugzilla – Bug 487581
Liberation Mono: incorrect spacing for Combining Diacritical Marks.
Last modified: 2010-10-12 06:47:33 EDT
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/2009020911 Ubuntu/8.10 (intrepid) Firefox/3.0.6
According to the bug on freedesktop.org (link below), Liberation Mono has an incorrect spacing definition for "Combining Diacritical Marks"; they should have zero space, and should render above the last letter, not the next one.
Paste following text with selected font:
Correct: accent above o
Incorrect: accent above g
Steps to Reproduce:
1. Enter a string with a combining diacritic mark in Liberation Mono, e.g., "o̍g". Don't use gnome-terminal; it relies on vte, which doesn't handle combining characters. Use something like gedit; switching fonts will reveal the issue as the diacritical mark switches places.
The diacritic appears one letter to the right of where it should be.
The diacritic should appear in the proper place.
I'm using ttf-liberation 1.04.93-1 on Ubuntu Intrepid; I'm filing this as an upstream bug. If this should be filed elsewhere, please let me know.
I'm filing this because several monospace fonts have incorrect spacing for "Combining Diacritical Marks":
Created attachment 333380 [details]
Video of the issue being triggered.
This video shows the diacritic changing position when the selected font is changed. Note that the diacritic moves to the right when Liberation Mono is selected.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
I downloaded the source and, I think, got the current (1.05.1.20090630) version to display in gedit. (I removed ttf-liberation, then placed the compiled fonts in ~/.fonts and ran "fc-cache ~/.fonts".)
Can I ask why this bug was closed? I wasn't reporting it against a particular version of Red Hat or Fedora; I don't run a version of Red Hat or Fedora. I was under the impression that this was the upstream bugtracker for the Liberation fonts--is there somewhere else I should be submitting this?
I'm setting this to ASSIGNED, because Bugzilla won't let me change it to anything else other than CLOSED.
As I said, I don't run a Red Hat-based OS, and the latest version packaged for anything Debian-based is 1.04.93. I performed the same test as the one shown in the attached video above, switching between the default Monospace font (I think it's DejaVu Sans Mono, but all I know for sure is that it isn't Liberation Mono, because the diacritics display properly) and what I'm reasonably sure is the new version of Liberation Mono.
When I do this, as in the video above, the diacritic hops from the top of the 'o' (where it should be) to the top of the 'g' (where it should not be).
Here's an easier way to reproduce it. Download "og.txt" (which I'll attach shortly) and run the following commands (you'll need the pango dev package for pango-view):
$ pango-view og.txt --font="DejaVu Sans Mono"
[Accent appears over the 'o']
$ pango-view og.txt --font="Liberation Mono"
[Accent appears over the 'g']
Does this make the problem more clear? It should be pretty trivial to reproduce.
Created attachment 350439 [details]
Text triggering the issue.
Hi, is "o̍g" the only combination with this problem that spotted by you? I could see if I could fix, given that it is not hinting problem.
Confirmed problem exists in 1.05.1.20090630
Hi Adam, could you test again with 1.05.1.20090706 please?
I just retested this on Ubuntu Karmic, which includes ttf-liberation version 1.05.1.20090721-0ubuntu1; the problem is still present, as before. (Apologies for the delay; it's difficult for me to test new versions of the fonts easily, as I haven't been able to come up with an easier way of checking.)
Thanks. I have planned to spend more time on this font set.
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '11'.
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 prior to Fedora 11's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 11 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 please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
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.
The process we are following is described here:
I have checked on Dejavu Mono. To have the font behave like what you said, it involved 3 chars 'o', 'uni030d', 'g'. Then, it needs 3 GSUB lookup tables - 'ccmp', 'dlig' and 'mark' - to convert into what you expected.
In fact I have checked version 1.02 which is the initial archive, there had been no uni030D glyph ever existed. Hence, I would certainly Liberation Fonts do not support the languages that consist of 'o̍g'.
Yes, you are always welcomed to request for this, but this is not a bug but a feature request. Thank you very much. Please file a ticket at upstream tracker:
I am closing this because this is not a bug.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.
More information and reason for this action is here:
While checking more on this i found there are characters from Range U+0300 to U+033E need GPOS rules for combining with previous characters.
Liberation is not supporting any of this shape, so this is not a bug.
Please report Request For Enhancements (RFE) if need this support, give information i.e in which language this thing is required etc