User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/20060314 Ubuntu/dapper Firefox/18.104.22.168
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20060314 Ubuntu/dapper Firefox/126.96.36.199
When certain fonts are chosen, the ligatures for 'fi' and 'fl' appear too close to the following letter. Sometimes, for words like "file", the "i" completely disappears. The fonts I noticed it with are the 'sans-serif' (generic, chosen by the fontconfig system, afaiui; default Ubuntu 'Dapper'), and 'Dejavu Sans'. When I switch to 'Verdana', there are no ligatures, so the problem does not manifest.
I will attach screenshots.
Created attachment 216243 [details]
Showing the 'fi' ligature.
Created attachment 216244 [details]
Showing the 'fl' ligature.
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a1) Gecko/20060325 Firefox/1.6a1 - Build ID: 0000000000
Works for me with Dejavu Sans.
What font-size have you set it to, and does anything change if you press Ctrl+0? (That's a zero.)
I reported this in Launchpad (the Ubuntu bug tracker) here:
The conditions necessary to trigger it are:
* using Pango for font rendering (the default with the Ubuntu Dapper packages).
* using a font with ligatures (e.g. DejaVu Sans -- the default sans-serif
font for Ubuntu Dapper).
* using "text-align: justify" or equivalent markup to get justified text.
It seems that the ligature glyph is drawn, but the advance of standard glyph for the first character is used, resulting in later characters being rendered over the top of the ligature.
I am not sure if this is an Ubuntu-only bug yet. It would be interesting to hear if people not using Ubuntu are able to reproduce the bug, when the above conditions are met.
Based on the comments at James Henstrige's blog post, http://blogs.gnome.org/view/jamesh/2006/04/03/0, it seems his question has been answered. People are seeing this on Debian (both in Firefox and Epiphany), OS X, FreeBSD, Mandriva, Gentoo... Looks like it's not distro-specific.
I also see this on Debian with the recent builds (which use pango). Could this bug be confirmed and the subject changed to:
'fi' and 'fl' ligatures too close to following letter in justified text when Pango is enabled
As Vincent says, this bug is not an Ubuntu only bug. It is just easier to hit on Ubuntu Dapper than other systems.
The prerequisites are:
1. A Firefox build with pango enabled.
2. Pango 1.12, which is the first version to use OpenType tables for
rendering latin text.
3. A font that contains OpenType ligature table entries, such as DejaVu (the
Bitstream Vera fonts contain some ligature glyphs but not the associated
OpenType tables that trigger their use by Pango).
The bug will then present itself on pages where the following hold:
1. The page requests one of the affected fonts (if an affected font is the
default serif or sans serif font, then this can be quite common).
2. The page must trigger the slow manual glyph placement code path, which
is used in the presence of non-default character or word spacing. The
"text-align: justify" CSS rule is one way to do this.
The bug has been observed with Firefox 188.8.131.52. In the Launchpad bug, one person posted a screenshot showing that Firefox 1.6a1 did not seem to be affected by the bug. I have not verified this personally though.
*** Bug 331694 has been marked as a duplicate of this bug. ***
I don't recommend using the existing Pango code. It's a hack started by Red Hat. It should really not be enabled by distributions except for locales where it's really needed (mostly Indic users).
Surely the Pango code is needed to correctly display the affected languages/scripts in any locale. That'd be why the distributions choose to use the Pango build instead.
For languages without complex script requirements, the non-Pango code is quite adequate. This includes European languages, most East Asian languages (CJK), and Hebrew. As far as I know, only Indic languages and Arabic (including Persian/Farsi) really benefit from the Pango path.
We are now working on full Pango integration but this won't be ready for quite some time.
What I was getting at is that a distro might want to be able to display more scripts than just the user's chosen locale (e.g. Ubuntu includes fonts for many different scripts in the default install). From this point of view, having Indic/Arabic text display correctly in non Indic/Arabic locales is desirable (especially in the web browser).
There is one modification to my steps to reproduce the bug: if using DejaVu to reproduce the bug, you must use a version < 2.5. The latest version doesn't include "liga" table entries for the ligatures in question, so the bug is not triggered (it seems that the change to the font was made because of this bug).
(In reply to comment #12)
> What I was getting at is that a distro might want to be able to display more
> scripts than just the user's chosen locale (e.g. Ubuntu includes fonts for
> many different scripts in the default install). From this point of view,
> having Indic/Arabic text display correctly in non Indic/Arabic locales is
> desirable (especially in the web browser).
It certainly is desirable! and we're working on it. It's just that with FF1.5/2 that requires some fairly nasty tradeoffs.
(In reply to comment #11)
> For languages without complex script requirements, the non-Pango code is quite
> adequate. This includes European languages, most East Asian languages (CJK),
> and Hebrew. As far as I know, only Indic languages and Arabic (including
> Persian/Farsi) really benefit from the Pango path.
As the 0th or even 1st-order approximation, what you wrote above is more or less right, but it's not that simple. See bug 215219 comment #97. Korean has complex script requirements (unfortunately, Pango's Korean support is inferior to that of ours because my patch to Pango a few years ago never got merged). So do Hebrew, Latin, and Greek.
(In reply to comment #13)
> It certainly is desirable! and we're working on it. It's just that with FF1.5/2
> that requires some fairly nasty tradeoffs.
In retrospect, my dirty hack in bug 215219 might have been an acceptable compromise for ff 1.5. With that, MathML still works well, Arabic/Hebrew work decently, and there's little performance loss for "non-complex" scripts.
BTW, the version field for this bug is set to 1.0branch, but that's not quite right given that ff 1.0 (gecko 1.7branch) branch does not contain blizzard's patch for bug 214715. RedHat and other distros ported the patch to ff 1.0 and still includes FF 1.0 instead of 1.5 (even Fedora Core 5 has 1.0.x whose PS printing module is not so good because bug 234182 was not fixed for FF1.0/Gecko 1.7). In our tree, it's not until gecko 1.8 that his patch was incorporated.
You can easily see this bug by going to google and searching for anything:
Here's and example: http://www.google.com/search?hl=en&lr=&q=Mozilla+Firefox&btnG=Search
What's the status of this bug? Has anyone been working on it?
This problem should be solved with the new textframe code. This code will be turned on in the Fx nightlies very soon, many at the start of next week.
Roc has indicated that he is taking into account the problem on his blog http://weblogs.mozillazine.org/roc/archives/2007/05/the_glyph_bound.html, and there are patches being developed to be sure it works in all cases http://weblogs.mozillazine.org/roc/archives/2007/05/things_ive_seen.html
The screenshots given with the original report shows as if the font maker forgot to adjust the Advance Width if the ligature glyph leaving it at the width used by the first letter of the combination. If this theory is correct, there is nothing that Mozilla should do.
(In reply to comment #18)
> The screenshots given with the original report shows as if the font maker
> forgot to adjust the Advance Width if the ligature glyph leaving it at the
> width used by the first letter of the combination. If this theory is
> correct, there is nothing that Mozilla should do.
It's already determined long ago that the bug was in Mozilla, and it has been fixed in Firefox 3.0.
Right, this is a 1.8 branch bug, i.e. Firefox 2 only.
IMO there's no reason to keep this open and we should WONTFIX it, as
- there's nobody strongly willing to take this bug and fix it in Firefox 2.
- even if there was someone willing to do that, I believe such a patch would have no chance of getting into the 2 branch which is now open about only for security fixes, right ?
WONTFIX may not be technically correct, but I'd certainly like to discourage anyone from wasting their time on this, so ... WONTFIX.