[Bug 14581] New: 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

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