Bug 6136 – WebKit should support automatic kerning

• Component: Layout and Rendering
• Status: RESOLVED FIXED

The CG code path in WebTextRenderer does not perform automatic kerning.

*** Bug 17970 has been marked as a duplicate of this bug. ***

[Mark Rowe (bdash)]

<rdar://problem/5811302>

[Dave Hyatt]

This is disabled on purpose for performance reasons.  In order to enable it, we'll have to find a way to kern without compromising rendering performance.

[Frank Illenberger]

Please consider making automatic kerning at least an opt-in feature. Pehaps by a custom -webkit-CSS attribute.
Firefox3 supports automatic kerning. For a nice comparison with Firefox check out:
http://opentype.info/blog/2008/06/14/kerning-and-opentype-features-in-firefox-3/

[Timothy Hatcher]

We should consider kerning text runs that are greater than some large font size. So headlines and things are kerned. That might be acceptable performance wise.

Setting a font size threshold may be problematic for things that smoothly
animate size.

[Frank Illenberger]

Small text should also be kerned during printing. But printing is most probably not performance critical.

[Beth Dakin]

Created attachment 40405 [details]
Patch

Here is a patch that implements the SVG text-rendering property as a regular HTML CSS property, just like in Firefox:

https://developer.mozilla.org/en/CSS/text-rendering

In this implmentation:
 auto = optimizeSpeed = what we normally when the value's not set
 optimizeLegibility = geometricPrecision = ligatures + kerning

Please note that this builds on Windows but doesn't do anything yet. I filed a Radar bug to track the Windows portion, and perhaps I will file a new bug here to track it too, or just keep this bug open to accept that patch shortly too.

[Sam Weinig]

Comment on attachment 40405 [details]
Patch

> Index: WebCore/ChangeLog
> ===================================================================
> --- WebCore/ChangeLog	(revision 48948)
> +++ WebCore/ChangeLog	(working copy)
> @@ -1,3 +1,90 @@
> [phone]  Beth Dakin  <[e-mail]>
> +
> +        Reviewed by NOBODY (OOPS!).
> +
> +        Fix for <rdar://problem/6934421> Support CSS for Text Kerning and 
> +        ligature
> +        -and corresponding-
> +        https://bugs.webkit.org/show_bug.cgi?id=6136
> +
> +        This patch makes the SVG CSS property text-rendering work with any 
> +        HTML, much like it does in Firefox. It accepts four possible input 
> +        values: auto, optimizeSpee, optimizeLegibility, and 

Typo "optimizeSpee". You also omit inherit, not sure if that is important. I think Dan should review the text stuff.

[Dave Hyatt]

Comment on attachment 40405 [details]
Patch

The .vcproj file seems to have unintentional additional changes in it.  Merge conflict issue maybe?

r=me

[Beth Dakin]

Thanks guys! I committed this with revision 48989.

[Frank Illenberger]

(In reply to comment #11)
> Thanks guys! I committed this with revision 48989.

Thanks for the nice feature. I tested it right away but found that ligatures are prevented by soft hyphens. Its even worse if a font contains contextual forms. The ligature engine believes to be at a word boundary when seeing the soft hyphen and renders the form for e.g. a word end in the middle of the word. 
I attached an example file showing the problems.

[Frank Illenberger]

Created attachment 40498 [details]
Example showing wrong ligatures being created when soft hyphens are used

[Frank Illenberger]

Created attachment 40499 [details]
Example showing weird editing and selection behavior if ligatures are rendered

[Frank Illenberger]

I added another example file which shows that it is nearly impossible to select or edit text which contains rendered ligatures.

[Timothy Hatcher]

Please file new bugs for the issues you find. This bug should be closed now, since a change has been made.

[Peter Kasting]

FWIW, bug 41363 is about making "auto" do the nice-but-slow path on fonts 20px and larger.  Maybe some people CCed here would like to add themselves there or implement that.

Another possibility, from https://bugzilla.mozilla.org/show_bug.cgi?id=595688 : apparently Firefox 4+ no longer has a "slow path" because it uses Harfbuzz to do shaping on all platforms, and that was fast enough that they could completely switch over without regressing perf.  Perhaps this makes sense for WebKit, or for particular ports of WebKit, as well; I don't know enough to file a bug, though.