RESOLVED FIXED 155004
Whitespace causes font-variant: all-small-caps to synthesize
https://bugs.webkit.org/show_bug.cgi?id=155004
Summary Whitespace causes font-variant: all-small-caps to synthesize
Myles C. Maxfield
Reported 2016-03-03 19:37:47 PST
Whitespace causes font-variant: all-small-caps to synthesize
Attachments
Patch (8.50 KB, patch)
2016-03-03 19:40 PST, Myles C. Maxfield
no flags
Archive of layout-test-results from ews101 for mac-yosemite (933.66 KB, application/zip)
2016-03-03 20:17 PST, Build Bot
no flags
Archive of layout-test-results from ews107 for mac-yosemite-wk2 (2.56 MB, application/zip)
2016-03-03 20:24 PST, Build Bot
no flags
Archive of layout-test-results from ews116 for mac-yosemite (910.88 KB, application/zip)
2016-03-03 20:47 PST, Build Bot
no flags
Patch (9.79 KB, patch)
2016-03-03 21:05 PST, Myles C. Maxfield
darin: review+
Myles C. Maxfield
Comment 1 2016-03-03 19:40:39 PST
Build Bot
Comment 2 2016-03-03 20:17:50 PST
Comment on attachment 272820 [details] Patch Attachment 272820 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/920110 New failing tests: fast/text/all-small-caps-whitespace.html
Build Bot
Comment 3 2016-03-03 20:17:54 PST
Created attachment 272823 [details] Archive of layout-test-results from ews101 for mac-yosemite The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews101 Port: mac-yosemite Platform: Mac OS X 10.10.5
Build Bot
Comment 4 2016-03-03 20:24:14 PST
Comment on attachment 272820 [details] Patch Attachment 272820 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/920135 New failing tests: fast/text/all-small-caps-whitespace.html
Build Bot
Comment 5 2016-03-03 20:24:16 PST
Created attachment 272824 [details] Archive of layout-test-results from ews107 for mac-yosemite-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews107 Port: mac-yosemite-wk2 Platform: Mac OS X 10.10.5
Build Bot
Comment 6 2016-03-03 20:47:42 PST
Comment on attachment 272820 [details] Patch Attachment 272820 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/920185 New failing tests: fast/text/all-small-caps-whitespace.html
Build Bot
Comment 7 2016-03-03 20:47:45 PST
Created attachment 272825 [details] Archive of layout-test-results from ews116 for mac-yosemite The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews116 Port: mac-yosemite Platform: Mac OS X 10.10.5
Myles C. Maxfield
Comment 8 2016-03-03 21:01:18 PST
Myles C. Maxfield
Comment 9 2016-03-03 21:05:15 PST
Darin Adler
Comment 10 2016-03-03 21:12:01 PST
Comment on attachment 272828 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=272828&action=review > Source/WebCore/platform/graphics/mac/ComplexTextController.cpp:309 > + bool result = nextFont && nextFont != Font::systemFallback(); I suggest using various early return false statements instead of the bool and all the &&-ing. > Source/WebCore/platform/graphics/mac/ComplexTextController.cpp:311 > + result &= !u_isUWhiteSpace(baseCharacter); Is this really the check we want? I know, for example, that it’s not a particularly fast function. Since what we are really doing is working around a bug in a font’s coverage data, it might be more efficient to just check for the space character, or maybe isASCIISpace. Using u_isUWhiteSpace seems both too broad and too narrow. I’m not sure I understand why whitespace is special. Maybe all uncased characters are special?
Myles C. Maxfield
Comment 11 2016-03-03 21:16:40 PST
Comment on attachment 272828 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=272828&action=review >> Source/WebCore/platform/graphics/mac/ComplexTextController.cpp:311 >> + result &= !u_isUWhiteSpace(baseCharacter); > > Is this really the check we want? I know, for example, that it’s not a particularly fast function. Since what we are really doing is working around a bug in a font’s coverage data, it might be more efficient to just check for the space character, or maybe isASCIISpace. Using u_isUWhiteSpace seems both too broad and too narrow. > > I’m not sure I understand why whitespace is special. Maybe all uncased characters are special? The difference is that smcp/c2sc does cover uncased characters (and it needs to in order for the uncased character not to look out of place). It doesn't, however, need to cover whitespace (presumably because, since there is no outline data, shrinking it would be a no-op)
Myles C. Maxfield
Comment 12 2016-03-03 21:24:20 PST
Comment on attachment 272828 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=272828&action=review >>> Source/WebCore/platform/graphics/mac/ComplexTextController.cpp:311 >>> + result &= !u_isUWhiteSpace(baseCharacter); >> >> Is this really the check we want? I know, for example, that it’s not a particularly fast function. Since what we are really doing is working around a bug in a font’s coverage data, it might be more efficient to just check for the space character, or maybe isASCIISpace. Using u_isUWhiteSpace seems both too broad and too narrow. >> >> I’m not sure I understand why whitespace is special. Maybe all uncased characters are special? > > The difference is that smcp/c2sc does cover uncased characters (and it needs to in order for the uncased character not to look out of place). It doesn't, however, need to cover whitespace (presumably because, since there is no outline data, shrinking it would be a no-op) It still should, though, because it isn't really a no-op - the glyph's advance should change too.
Myles C. Maxfield
Comment 13 2016-03-04 11:09:30 PST
Note You need to log in before you can comment on or make changes to this bug.