Last Comment Bug 331716 - 'fi' and 'fl' ligatures overlap following glyph with justified text in pango builds
: 'fi' and 'fl' ligatures overlap following glyph with justified text in pango ...
Status: RESOLVED WONTFIX
:
Product: Core Graveyard
Classification: Graveyard
Component: GFX: Gtk (show other bugs)
: 1.8 Branch
: x86 Linux
: -- normal with 8 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://en.wikipedia.org/wiki/Peephole...
: 331694 (view as bug list)
Depends on: 367177
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-25 13:00 PST by Karl Hegbloom
Modified: 2010-09-18 09:43 PDT (History)
26 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Showing the 'fi' ligature. (3.58 KB, image/png)
2006-03-25 13:00 PST, Karl Hegbloom
no flags Details
Showing the 'fl' ligature. (5.00 KB, image/png)
2006-03-25 13:01 PST, Karl Hegbloom
no flags Details

Description Karl Hegbloom 2006-03-25 13:00:07 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060314 Ubuntu/dapper Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060314 Ubuntu/dapper Firefox/1.5.0.1

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.

Reproducible: Always




I will attach screenshots.
Comment 1 Karl Hegbloom 2006-03-25 13:00:59 PST
Created attachment 216243 [details]
Showing the 'fi' ligature.
Comment 2 Karl Hegbloom 2006-03-25 13:01:37 PST
Created attachment 216244 [details]
Showing the 'fl' ligature.
Comment 3 Philip Withnall (unavailable) 2006-03-26 07:21:22 PST
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.)
Comment 4 James Henstridge 2006-04-02 23:56:49 PDT
I reported this in Launchpad (the Ubuntu bug tracker) here:
    https://launchpad.net/distros/ubuntu/+source/firefox/+bug/37828

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.
Comment 5 Robin Munn 2006-04-03 11:06:08 PDT
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.
Comment 6 Vincent Lefevre 2006-04-05 06:33:58 PDT
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
Comment 7 James Henstridge 2006-04-11 06:01:14 PDT
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 1.5.0.1.  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.
Comment 8 dolphinling 2006-04-13 18:31:31 PDT
*** Bug 331694 has been marked as a duplicate of this bug. ***
Comment 9 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-04-17 20:51:18 PDT
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).
Comment 10 James Henstridge 2006-04-17 23:46:17 PDT
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.
Comment 11 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-04-18 01:48:09 PDT
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.
Comment 12 James Henstridge 2006-04-19 00:50:50 PDT
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).
Comment 13 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-04-19 01:23:56 PDT
(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.
Comment 14 Jungshik Shin 2006-04-19 02:04:19 PDT
(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.
Comment 15 Blade McNeil 2006-07-28 02:23:57 PDT
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
Comment 16 keenanpepper 2007-05-30 13:36:23 PDT
What's the status of this bug? Has anyone been working on it?
Comment 17 Jean-Marc Desperrier 2007-05-31 11:19:38 PDT
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
Comment 18 JC Ahangama 2008-08-21 11:05:52 PDT
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.
Comment 19 Ben Laenen 2008-08-21 11:15:23 PDT
(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.
Comment 20 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2008-08-21 15:07:54 PDT
Right, this is a 1.8 branch bug, i.e. Firefox 2 only.
Comment 21 Jean-Marc Desperrier 2008-08-25 02:26:32 PDT
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 ?

Comment 22 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2008-08-25 02:30:01 PDT
WONTFIX may not be technically correct, but I'd certainly like to discourage anyone from wasting their time on this, so ... WONTFIX.

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