[Webkit-unassigned] [Bug 108881] New: Canvas fillText and measureText handle ideographic spaces differently

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=108881

           Summary: Canvas fillText and measureText handle ideographic
                    spaces differently
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Macintosh Intel
        OS/Version: Mac OS X 10.6
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Canvas
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: parrott.jason at gmail.com


Created an attachment (id=186505)
 --> (https://bugs.webkit.org/attachment.cgi?id=186505&action=review)
Demo showing bug.

This is a bug first created over on chromium's issue tracker here: http://code.google.com/p/chromium/issues/detail?id=171639

Steps to reproduce the problem:
1. Call canvas 2d context's measureText() twice. Once with \u0020 (ascii space) and once with ideographic space (\u3000).
2. Notice the width returned are different.
3. Call canvas 2d context's fillText() twice. Once with \u0020 (ascii space) and once with ideographic space (\u3000).
4. Notice how the results are the same. Both are rendered as a normal ascii space.

What is the expected behavior?
The width of the space shown with fillText should be the same as the width calculated by measureText.

What went wrong?
There are actually several things going on here.

Specification-wise, in the current stable and dev w3c versions of Canvas,
( http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas/#text-preparation-algorithm )
text passed in to both measureText and fillText needs to have all space characters replaced with ASCII space characters.
However the definition of 'space character' is undefined.

In whatwg,
( http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#text-preparation-algorithm )
The spec says to replace space characters again, however this time with a definition.
( http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#space-character )
Note that ideographic space (U+3000) is not in that definition.

Both measureText and fillText are supposed to use this same algorithm for replacing text and should therefore have the same result when doing things with space widths.

Code-wise the problem can be easily found (if I'm reading this correctly).

http://git.chromium.org/gitweb/?p=external/Webkit.git;a=blob;f=Source/WebCore/html/canvas/CanvasRenderingContext2D.cpp;hb=HEAD#l2218

measureText is not trying to replace anything. Which in itself is a bug.

http://git.chromium.org/gitweb/?p=external/Webkit.git;a=blob;f=Source/WebCore/html/canvas/CanvasRenderingContext2D.cpp;hb=HEAD#l2266

drawTextInternal does replace spaces using replaceCharacterInString(normalizedText, isSpaceOrNewline, " ");
However, isSpaceOrNewline (if I'm following the code correctly), matches all BIDI WS characters, including ideographic space.
This will replace all white space characters with ASCII space which is both specification-wise incorrect and language-wise annoying.

In Japanese the standard space is the ideographic space and if you replace that with ASCII space in a sentence the sentence becomes difficult to read as it is not what people are used to (as it is half the size).

At any rate, measureText and drawTextInternal are doing things differently while they should be doing the same thing.

Please see the attached file for a demo of this breaking.
Note that this uses the Japanese Osaka font to demonstrate easily.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.