WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
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
Details
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
Details
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
Details
Patch
(9.79 KB, patch)
2016-03-03 21:05 PST
,
Myles C. Maxfield
darin
: review+
Details
Formatted Diff
Diff
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
Myles C. Maxfield
Comment 1
2016-03-03 19:40:39 PST
Created
attachment 272820
[details]
Patch
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
<
rdar://problem/24630796
>
Myles C. Maxfield
Comment 9
2016-03-03 21:05:15 PST
Created
attachment 272828
[details]
Patch
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
Committed
r197573
: <
http://trac.webkit.org/changeset/197573
>
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