Summary: | LayoutTests/canvas/philip/tests/2d.text.draw.space.collapse.nonspace.html is against the spec | ||
---|---|---|---|
Product: | WebKit | Reporter: | Rashmi Shyamasundar <rashmi.s2> |
Component: | Canvas | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED WONTFIX | ||
Severity: | Normal | CC: | ap, bfulgham, cdumez, ian, krit, mrobinson, rashmi.shyam |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Description
Rashmi Shyamasundar
2013-08-08 02:23:11 PDT
I am trying to fix the implementation as part of patch to the bug - https://bugs.webkit.org/show_bug.cgi?id=108881 There is a bug on W3C for the same test case :- https://www.w3.org/Bugs/Public/show_bug.cgi?id=15925 And, the proposed patch in this W3C bug is to :- replace the line "ctx.fillText('E\x0b EE', -150, 37.5);" with "ctx.fillText('E\x0b EE', -100, 37.5);" How do other browsers (Firefox 23 / IE10) behave? (In reply to comment #3) > How do other browsers (Firefox 23 / IE10) behave? The test passes on Firefox 23, WebKit and Blink. It fails on IE10 but apparently due to lack of support: "Aborted with exception: Object doesn't support property or method 'getContext'" So it seems Chrome / Safari / Firefox and currently in sync. I would not change our behavior despite what the specification says. According to this draft spec - http://www.w3.org/html/wg/drafts/html/master/single-page.html#space-character , U+000B is an undefined Unicode character and its usage should result in a parse error. Extracted from the above link :- Any occurrences of any characters in the ranges U+0001 to U+0008, U+000E to U+001F, U+007F to U+009F, U+FDD0 to U+FDEF, and characters U+000B, U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, U+2FFFE, U+2FFFF, U+3FFFE, U+3FFFF, U+4FFFE, U+4FFFF, U+5FFFE, U+5FFFF, U+6FFFE, U+6FFFF, U+7FFFE, U+7FFFF, U+8FFFE, U+8FFFF, U+9FFFE, U+9FFFF, U+AFFFE, U+AFFFF, U+BFFFE, U+BFFFF, U+CFFFE, U+CFFFF, U+DFFFE, U+DFFFF, U+EFFFE, U+EFFFF, U+FFFFE, U+FFFFF, U+10FFFE, and U+10FFFF are parse errors. These are all control characters or permanently undefined Unicode characters (noncharacters). This test seems bogus to me -- how do you know what the font will draw U+000B as? A better test would be something like comparing these two calls: ctx.fillText("E \x0b E", ... ctx.fillText("E E", ... ...to see if the two spaces collapse into one. There should probably also be a separate test that checks the text in: http://www.w3.org/TR/css3-text/#white-space-processing ...saying that control characters in general should be ignored... As discussed with Mr. Christophe Dumez :- The test passes on Chrome / Safari and Firefox. Our behavior should be in sync with others, despite what the specification says. We deleted this test suit from LayoutTests a while ago. suite* |