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;}
The brokenness of the end result is a regression, but at least TOT gets the font right, unlike shipping Safari.
Created attachment 8953 [details] A test case I'm not sure what kind of reduction you need, but I did this anyway.
I see the "bold font doubling' bug. Is that the issue you're describing? If so I think this is a dup.
That is the only thing I'm seeing. Will look for the duplicate.
*** This bug has been marked as a duplicate of 9362 ***
Since bug 9362 was closed as WORKSFORME, reopening this one.
Created attachment 9049 [details] screenshot
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.
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.
<rdar://problem/4614197>
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.
Created attachment 12207 [details] Bold was too pronounced. Better patch. Here's a better version with updated math.
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.
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.
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).
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).
(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.
Created attachment 12215 [details] True bold: Helvetica
Created attachment 12216 [details] Faux bold: Geneva, non-scaled (Hyatt's current patch)
Created attachment 12217 [details] Faux bold: Geneva, scale to maintain x height
Created attachment 12218 [details] Faux bold: Geneva, scale to maintain ascender
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).
Can you show a patch that does the ascender scaling?
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 :-) )
Lowering the priority of this bug since I checked in a fix to just always use 1.0 as the synthetic bold offset.