Bug 9534 - Improve synthetic bold
Summary: Improve synthetic bold
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Text (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://mjtsai.com/blog/2005/12/11/iph...
Keywords: HasReduction, InRadar
Depends on:
Blocks:
 
Reported: 2006-06-21 11:26 PDT by Rachael Worthington (cheers)
Modified: 2019-06-19 17:09 PDT (History)
8 users (show)

See Also:


Attachments
A test case (497 bytes, text/html)
2006-06-21 13:18 PDT, jonathanjohnsson
no flags Details
screenshot (17.59 KB, image/png)
2006-06-26 10:26 PDT, Alexey Proskuryakov
no flags Details
Better approach to bold (2.83 KB, patch)
2007-01-03 23:30 PST, Dave Hyatt
no flags Details | Formatted Diff | Diff
Bold was too pronounced. Better patch. (2.82 KB, patch)
2007-01-03 23:37 PST, Dave Hyatt
no flags Details | Formatted Diff | Diff
Test case (1.56 KB, text/html)
2007-01-03 23:40 PST, Dave Hyatt
no flags Details
Switch ATSU over to the new stroke technique as well. (6.10 KB, patch)
2007-01-04 00:40 PST, Dave Hyatt
no flags Details | Formatted Diff | Diff
True bold: Helvetica (11.57 KB, image/png)
2007-01-04 06:37 PST, mitz
no flags Details
Faux bold: Geneva, non-scaled (Hyatt's current patch) (14.64 KB, image/png)
2007-01-04 06:39 PST, mitz
no flags Details
Faux bold: Geneva, scale to maintain x height (13.86 KB, image/png)
2007-01-04 06:39 PST, mitz
no flags Details
Faux bold: Geneva, scale to maintain ascender (14.21 KB, image/png)
2007-01-04 06:41 PST, mitz
no flags Details
Patch w/ascender scaling (6.37 KB, patch)
2007-01-04 12:05 PST, mitz
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Rachael Worthington (cheers) 2006-06-21 11:26:08 PDT
load the above URL in Safari and in a recent WebKit nightly, and observe the differences. The CSS page is http://mjtsai.com/styles.css defines the h1 style as
h1, h2, h3, h4 { font-family: "Big Caslon", Cochin, Optima, Sans-Serif; color: #000000;}
Comment 1 Alexey Proskuryakov 2006-06-21 11:54:43 PDT
The brokenness of the end result is a regression, but at least TOT gets the font right, unlike shipping Safari.
Comment 2 jonathanjohnsson 2006-06-21 13:18:36 PDT
Created attachment 8953 [details]
A test case

I'm not sure what kind of reduction you need, but I did this anyway.
Comment 3 Dave Hyatt 2006-06-21 13:21:20 PDT
I see the "bold font doubling' bug.  Is that the issue you're describing?  If so I think this is a dup.
Comment 4 jonathanjohnsson 2006-06-21 13:28:16 PDT
That is the only thing I'm seeing. Will look for the duplicate.
Comment 5 Darin Adler 2006-06-24 20:07:59 PDT

*** This bug has been marked as a duplicate of 9362 ***
Comment 6 Alexey Proskuryakov 2006-06-26 10:25:01 PDT
Since bug 9362 was closed as WORKSFORME, reopening this one.
Comment 7 Alexey Proskuryakov 2006-06-26 10:26:36 PDT
Created attachment 9049 [details]
screenshot
Comment 8 mitz 2006-06-26 12:23:45 PDT
As far as I can tell, everything is behaving as expected in this case (font selection, deciding to use synthetic bold, computing the synthetic bold offset), but the result is just unacceptable. According to Daring and Dave Hyatt, there is an alternative way to synthesize bold. Perhaps that's the solution needed here.
Comment 9 Darin Adler 2006-06-29 08:16:40 PDT
I'm not sure this really qualifies as a regression, but it is true that the boldness would be entirely ignored with the old version of Safari -- we should research the better approach to synthesized bold.
Comment 10 Alice Liu 2006-07-05 14:20:05 PDT
<rdar://problem/4614197>
Comment 11 Dave Hyatt 2007-01-03 23:30:30 PST
Created attachment 12206 [details]
Better approach to bold

This patch illustrates the better bold approach.  It synthesizes bold by creating a thickening effect using stroking.  I'm not requesting review though, since I am having trouble figuring out how to get the effect I want using the ATSU code path.

The ATSU code path looks totally bogus to me right now, since it seems like it will do an overstrike of the entire run if any FontData at all in some sub-section of the run has synthetic bold.
Comment 12 Dave Hyatt 2007-01-03 23:37:14 PST
Created attachment 12207 [details]
Bold was too pronounced.  Better patch.

Here's a better version with updated math.
Comment 13 Dave Hyatt 2007-01-03 23:39:01 PST
It's worth noting that although stroking looks better than overstriking, if we just reduce the current synthetic bold offset to the value in the stroking patch, then even the overstrike technique looks acceptable.

Comment 14 Dave Hyatt 2007-01-03 23:40:44 PST
Created attachment 12208 [details]
Test case

Here's a test case that shows a comparison of stroke (simple text) vs. overstrike (complex text).  

Transparent text actually looks funnier at large sizes using the stroke technique, since an "outline" starts to form.
Comment 15 Dave Hyatt 2007-01-04 00:12:14 PST
Ok, I was wrong about the overstrike being buggy in the ATSU case.  It does 2 passes and only does the overstrike for renderers that are truly synthetic bold (it throws in the space glyph instead for those that aren't to avoid drawing anything).
Comment 16 Dave Hyatt 2007-01-04 00:40:36 PST
Created attachment 12209 [details]
Switch ATSU over to the new stroke technique as well.

Ok, this patch finishes the job.  I do see occasional 1px rounding errors regarding baseline alignment.  I'm not sure if there's really any way around that.

One argument for overstrike I suppose is that it has no effect on vertical metrics.  The stroke technique does have the effect of making the font taller (but that also helps keep the thickening in proportion so that you don't get wide squat characters).
Comment 17 David Kilzer (:ddkilzer) 2007-01-04 05:21:20 PST
(In reply to comment #5)
> *** This bug has been marked as a duplicate of 9362 ***

(In reply to comment #6)
> Since bug 9362 was closed as WORKSFORME, reopening this one.

Technically this is also a Google bug.

Comment 18 mitz 2007-01-04 06:37:42 PST
Created attachment 12215 [details]
True bold: Helvetica
Comment 19 mitz 2007-01-04 06:39:07 PST
Created attachment 12216 [details]
Faux bold: Geneva, non-scaled (Hyatt's current patch)
Comment 20 mitz 2007-01-04 06:39:52 PST
Created attachment 12217 [details]
Faux bold: Geneva, scale to maintain x height
Comment 21 mitz 2007-01-04 06:41:00 PST
Created attachment 12218 [details]
Faux bold: Geneva, scale to maintain ascender
Comment 22 mitz 2007-01-04 06:49:05 PST
As you can see in the Helvetica sample, true bold maintains both the x-height and the ascender. The current patch maintains the baseline, but increases the x-height and the ascender. By applying horizontal scaling, it is possible to restore either the x-height or the ascender (but obviously not both at the same time). I think the "maintain ascender" option gives the best-looking result. Note that scaling is horizontal only. I think this is consistent with true bold, where glyphs are typically wider but not taller (again, see the lowercase m, s and g in the Helvetica sample).
Comment 23 Dave Hyatt 2007-01-04 11:54:36 PST
Can you show a patch that does the ascender scaling?
Comment 24 mitz 2007-01-04 12:05:11 PST
Created attachment 12221 [details]
Patch w/ascender scaling

(In reply to comment #23)
> Can you show a patch that does the ascender scaling?
> 

Just added these lines:
+    if (font->m_syntheticBoldOffset)
+        matrix = CGAffineTransformScale(matrix, 1.0f, [drawFont ascender] / ([drawFont ascender] + font->m_syntheticBoldOffset));

(Didn't do ATSUI :-) )
Comment 25 Dave Hyatt 2007-01-04 13:30:56 PST
Lowering the priority of this bug since I checked in a fix to just always use 1.0 as the synthetic bold offset.