RESOLVED FIXED 144151
[iOS] Reimplement r182512 and r183153 in a cleaner way 
https://bugs.webkit.org/show_bug.cgi?id=144151
Summary [iOS] Reimplement r182512 and r183153 in a cleaner way
Myles C. Maxfield
Reported 2015-04-24 10:41:29 PDT
Reimplement r182512 and r183153 in a cleaner way
Attachments
Patch (8.73 KB, patch)
2015-04-24 10:51 PDT, Myles C. Maxfield 		enrica: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Myles C. Maxfield
Comment 1 2015-04-24 10:51:11 PDT
Created attachment 251559 [details] Patch
Enrica Casucci
Comment 2 2015-04-24 10:58:53 PDT
Comment on attachment 251559 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=251559&action=review > Source/WebCore/platform/graphics/cocoa/FontPlatformDataCocoa.mm:-272 > -#endif // !PLATFORM(IOS) Where did all the logic for cascadeToLastResortAndDisableSwashesFontDescriptor go? Are you sure this code is equivalent on iOS?
Myles C. Maxfield
Comment 3 2015-04-24 11:06:58 PDT
Comment on attachment 251559 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=251559&action=review >> Source/WebCore/platform/graphics/cocoa/FontPlatformDataCocoa.mm:-272 >> -#endif // !PLATFORM(IOS) > > Where did all the logic for cascadeToLastResortAndDisableSwashesFontDescriptor go? Are you sure this code is equivalent on iOS? It's above, see line 265. The logic between the two code paths is exactly the same; the only difference is which underlying creation API we call. On OS X, we call CTFontCreateCopyWithAttributes() if we can, and CTFontCreateWithGraphicsFont() otherwise. Before this patch, on iOS, we would just always call CTFontCreateWithGraphicsFont (which has the problematic quality of losing system-font-ness). So the logic is the same, we're just switching to a different (and superior) API call.
Myles C. Maxfield
Comment 4 2015-04-24 11:46:23 PDT
Committed r183271: <http://trac.webkit.org/changeset/183271>
Note You need to log in before you can comment on or make changes to this bug.