If a bold version of a particular font is requested but none exists on the system, Web Kit does not properly synthesize a font. Instead it honors the weight but falls back to another font. Instead it should synthesize a font with the appropriate weight.
If the font has an fvar weight axis, this can be used instead of synthesizing a heavier typeface. Possibly another bug should be opened to track this though, as fvar can be used for features other than just weight. Test case at http://web.nickshanks.com/safari/fvar
*** Bug 3494 has been marked as a duplicate of this bug. ***
Nick, the test case mentioned in comment #1 doesn't appear to be accessible at present. Would it be possible to attach it to the bug so that it will always be available?
Yes, the fvar possibility should be a separate bug.
Created attachment 3844 [details] add synthesized bold and oblique, other related renderer improvements
In Radar as <rdar://problem/3256269>.
I think you have a problem in your order-swapping loop in _CG_drawRun:style:geometry:. You're decrementing end by 3 in each iteration.
Oops! You're right. I have to move that -- out! I'll have to make sure to run pixel tests rather than just layout tests. I'm leaving this patch in review? anyway so that Dave Hyatt can review it -- but he should review- it due to that bad mistake.
Comment on attachment 3844 [details] add synthesized bold and oblique, other related renderer improvements Just a personal preference, but I like style.rtl over style.RTL. Unless you feel really strongly, I'd rather this just stay the way it is currently. Looks good, but fix the mistake already pointed out, and I'll re-review.
Opened bug #5168 to cover fvar
Created attachment 4106 [details] revised patch fixing bug Mitz noticed, and with RTL back to rtl as requested
Comment on attachment 4106 [details] revised patch fixing bug Mitz noticed, and with RTL back to rtl as requested r=me, make sure to run perf tests and layout tests to make sure we have no regressions.