709 bytes, text/html
2.06 KB, patch
|Details | Diff | Splinter Review|
2.39 KB, patch
|Details | Diff | Splinter Review|
Created attachment 8531604 [details] example showing soft hyphen rendered as a block User Agent: Mozilla/5.0 (Windows NT 5.1; rv:34.0) Gecko/20100101 Firefox/34.0 Build ID: 20141126041045 Steps to reproduce: Call fillText on canvas rendering context using a string containing a soft hyphen. Actual results: The soft hyphen renders as a zero-width block (like an unknown character). Expected results: Soft hyphens should be ignored. They are ignored during normal html rendering. All other browsers tested (Chrome, Safari, IE) ignore soft hyphens in canvas drawing operations too.
Actually, the same happens for the zero width space character ("\u200B")
Created attachment 8531619 [details] example showing zero-width unicode characters rendered as a block
Attachment #8531604 - Attachment is obsolete: true
I've just replaced the example code. There are several zero-width unicode characters that show up as a block (soft hypen, ZWSP, ZWNJ, ZWJ). Having run the example on browserstack, FF on OSX seems to render only ZWSP as a block. However, all of those characters are rendered as a block on Windows.
I can reproduce this on Nightly on Windows 8.1, although Nightly shows an Ã instead of a box (which beta shows) for the first input. Chrome just shows the __, and no boxes at all. Jonathan, is this fonts-related, or canvas-related, or both? :-)
Status: UNCONFIRMED → NEW
Component: Untriaged → Untriaged
Ever confirmed: true
Keywords: reproducible, testcase
Product: Firefox → Core
This issue, or at least some part of it, was recently fixed in bug 1108179. Could you please re-test with latest Nightly builds and confirm whether there are still some remaining problems? Thanks!  https://nightly.mozilla.org/
Flags: needinfo?(jfkthame) → needinfo?(szdy12)
Just tested with Nightly 38.0a1 (2015-02-08) on XP. Soft hyphen renders as an Ã. All other characters render OK (do not show up anything). Soft hyphen is unicode 0xAD, so it's in the 8-bit code range of whatever encoding the OS uses. ZWSP, ZWNJ, ZWJ are > 0x2000
Nightly 41.0a1 (2015-05-26) on Windows 7 SP1 64bit soft hyphen: Ã ZWSP: OK ZWNJ, ZWJ: block
(In reply to Jonathan Kew (:jfkthame) from comment #5) > This issue, or at least some part of it, was recently fixed in bug 1108179. > Could you please re-test with latest Nightly builds and confirm whether > there are still some remaining problems? Thanks! > > >  https://nightly.mozilla.org/ Looks like this is still there per comment #6 / comment #7. Can you investigate further? :-)
Created attachment 8612914 [details] [diff] [review] Suppress improper drawing of zero-width invisible glyphs in canvas This prevents us rendering spurious glyphs for zero-width invisibles that were not explicitly supported by the font, which is what's happening here.
Attachment #8612914 - Flags: review?(roc)
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Although originally filed for Windows, this isn't really platform-specific; I can reproduce a similar glitch on OS X by changing the default sans-serif font to Arial (instead of Helvetica), for example, or by explicitly specifying Arial in the script. It just depends on the used font's support (or lack of it) for the zero-width invisible characters involved.
Component: Untriaged → Canvas: 2D
OS: Windows XP → All
Hardware: x86 → All
Version: 34 Branch → Trunk
Attachment #8612914 - Flags: review?(roc) → review+
Created attachment 8613225 [details] [diff] [review] Reftest for zero-width invisible glyphs in canvas Here's the testcase from this bug in reftest form, which I'll push along with the patch.
https://hg.mozilla.org/mozilla-central/rev/97ab325b1cfb https://hg.mozilla.org/mozilla-central/rev/7a1fa81730e4 https://hg.mozilla.org/mozilla-central/rev/0c7557ef0612
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox41: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
You need to log in before you can comment on or make changes to this bug.