WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
9534
Improve synthetic bold
https://bugs.webkit.org/show_bug.cgi?id=9534
Summary
Improve synthetic bold
Rachael Worthington (cheers)
Reported
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;}
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
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1
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.
jonathanjohnsson
Comment 2
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.
Dave Hyatt
Comment 3
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.
jonathanjohnsson
Comment 4
2006-06-21 13:28:16 PDT
That is the only thing I'm seeing. Will look for the duplicate.
Darin Adler
Comment 5
2006-06-24 20:07:59 PDT
*** This bug has been marked as a duplicate of
9362
***
Alexey Proskuryakov
Comment 6
2006-06-26 10:25:01 PDT
Since
bug 9362
was closed as WORKSFORME, reopening this one.
Alexey Proskuryakov
Comment 7
2006-06-26 10:26:36 PDT
Created
attachment 9049
[details]
screenshot
mitz
Comment 8
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.
Darin Adler
Comment 9
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.
Alice Liu
Comment 10
2006-07-05 14:20:05 PDT
<
rdar://problem/4614197
>
Dave Hyatt
Comment 11
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.
Dave Hyatt
Comment 12
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.
Dave Hyatt
Comment 13
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.
Dave Hyatt
Comment 14
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.
Dave Hyatt
Comment 15
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).
Dave Hyatt
Comment 16
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).
David Kilzer (:ddkilzer)
Comment 17
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.
mitz
Comment 18
2007-01-04 06:37:42 PST
Created
attachment 12215
[details]
True bold: Helvetica
mitz
Comment 19
2007-01-04 06:39:07 PST
Created
attachment 12216
[details]
Faux bold: Geneva, non-scaled (Hyatt's current patch)
mitz
Comment 20
2007-01-04 06:39:52 PST
Created
attachment 12217
[details]
Faux bold: Geneva, scale to maintain x height
mitz
Comment 21
2007-01-04 06:41:00 PST
Created
attachment 12218
[details]
Faux bold: Geneva, scale to maintain ascender
mitz
Comment 22
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).
Dave Hyatt
Comment 23
2007-01-04 11:54:36 PST
Can you show a patch that does the ascender scaling?
mitz
Comment 24
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 :-) )
Dave Hyatt
Comment 25
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.
Karl Dubost
Comment 26
2024-01-24 00:54:47 PST
<
rdar://problem/4614197
>
Brent Fulgham
Comment 27
2024-03-07 14:23:32 PST
This issue is now tracked by: <
rdar://7769181
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug