- From: <bugzilla@jessica.w3.org>
- Date: Thu, 27 Oct 2011 22:54:31 +0000
- To: public-html@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14581 Summary: filing a separate feature request as requested in http://www.w3.org/Bugs/Public/show_bug.cgi?id=14562 --- Please add support for multiline text. more people than you think want to use graphics-manipulable text on their canvas. As the graphics contact for Product: HTML WG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: HTML Canvas 2D Context (editor: Ian Hickson) AssignedTo: ian@hixie.ch ReportedBy: contributor@whatwg.org QAContact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-wg-issue-tracking@w3.org, public-html@w3.org Specification: http://www.w3.org/TR/2dcontext/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: filing a separate feature request as requested in http://www.w3.org/Bugs/Public/show_bug.cgi?id=14562 --- Please add support for multiline text. more people than you think want to use graphics-manipulable text on their canvas. As the graphics contact for canvas2D is expressly not a text element, please undo the decision to treat text rasterised onto it the same as text intended for page placing, and treat whitespace characters such as spaces and newlines as distinct instructions. This will still not break work already done by people so far because they will have implemented their workarounds to do exactly what a proper implementation would do anyway. In response to the comment that "if you need multiline text, you are almost certainly misusing canvas for something that is better done either using straight HTML and CSS, or at a pinch using SVG", this sounds like a comment made under an assumption about text that is generally not true, and misses an important distinction in what "text" means: there is a difference between typographical text (i.e. the text you read and understand as representing a language construct), and graphics based on text (i.e. using text as a pixel stencil, using it for artistic purposes). I wholly agree that the canvas is not for typographical text. We already have HTML+CSS and even SVG, and we don't need yet another element for rendering text for reading. But, thinking that thought through, this has as immediate consequence that using the same constraints for text on a canvas as are in place for typographical text on a webpage makes no sense. If canvas is not for typographical text as part of a webpage, why implicitly pretend it's typographical text on a webpage anyway by using those constraints? People who are used to working with rasterised text as graphics --expressly NOT as typographical text-- from applications such as Photoshop, Paint.net, The Gimp, etc. are used to the text being typeset the way they dictate it (multiple spaces being multiple spaces, newlines acting as line breaks, etc.) so that they can then manipulate the graphics context with that text firmly rasterised on it, not acting as text at all, but as pixels that can be copied, mixed, and overwritten. Not all text is language. Sometimes (and definitely in raster graphics contexts such as the 2d canvas) it's just a graphics primitive, and should just be rendered as such. Posted from: 205.250.164.138 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.187 Safari/535.1 -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Thursday, 27 October 2011 22:54:37 UTC