This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html Section: http://www.whatwg.org/specs/web-apps/current-work/complete.html#dom-context-2d-font Comment: My worry is that this doesn't cover all the different kinds of textual transformations. Yes, it does cover obliqueness and weight, it does not cover letter spacing and other textual attributes that may be of some use to developers. Posted from: 66.169.241.62
It seems to me that a reasonable solution to this is to allow the rendering of an arbitrary HTML element to the canvas. I don't think you want to duplicate all of CSS's text functionality in the canvas 2D context itself. You probably want to allow some size to be passed in when doing this (so that text could wrap), too. And it would be pretty handy if you could also just pass in a string to be parsed: var ctx = ...; ctx.drawHTML("<span style='letter-spacing: -0.1; font-weight: 100'>Well <i>hello</i> there!", 100, 100, 500); where the (100, 100) is the top-left corner of the area in which to lay out the CSS boxes, and 500 is the width.
(In reply to comment #1) > It seems to me that a reasonable solution to this is to allow the rendering of > an arbitrary HTML element to the canvas. I don't think you want to duplicate > all of CSS's text functionality in the canvas 2D context itself. You probably > want to allow some size to be passed in when doing this (so that text could > wrap), too. > > And it would be pretty handy if you could also just pass in a string to be > parsed: > > var ctx = ...; > ctx.drawHTML("<span style='letter-spacing: -0.1; font-weight: 100'>Well > <i>hello</i> there!", 100, 100, 500); > > where the (100, 100) is the top-left corner of the area in which to lay out the > CSS boxes, and 500 is the width. You'd need a height as well (though a value that means 'auto' would be useful for both). Don't forget about vertical languages. ^_^ Anyway, +1 on an idea in this direction.
I should provide more than a +1. Drawing arbitrary text into a canvas lets you do a lot of things, like render text with sub/superscripts, ruby, etc. These require either structured rendering, like HTML+CSS would provide, or a lot more work to measure text widths and position things yourself.
Yes, good point. The width & height arguments should be strings, which are parsed as CSS lengths. They could be optional and default to 'auto'. Another thing to consider is how style resolution would work. Would style rules in the document apply to the elements that are parsed from the argument? Would properties be inherited from somewhere (the <canvas> element, maybe)?
(In reply to comment #4) > Yes, good point. The width & height arguments should be strings, which are > parsed as CSS lengths. They could be optional and default to 'auto'. Strings or numbers. Numbers would be canvas pixels, presumably (or maybe CSS px). > Another thing to consider is how style resolution would work. Would style > rules in the document apply to the elements that are parsed from the argument? > Would properties be inherited from somewhere (the <canvas> element, maybe)? Ooh, didn't think of that. Inheriting from the <canvas> is an interesting idea. Either that, or no inheritance at all - all values are set to initial.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: none yet Rationale: More features for rendering text, and more features for rendering arbitrary markup, are things on the cards for a revision of the canvas API once the rest of the spec is more firmly implemented. We don't want to get too far ahead of the implementations. As such, I've marked this LATER, so that it doesn't drop off the radar.
mass-move component to LC1
This bug is a bit open-ended. It might be better to file separate bugs for specific things that you think we should offer control over.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: I'm going to add the ability to draw text to a path, which gives you some more control. I'm not sure what specifically else should be added; text spacing is the only other thing listed in this bug but you can fake that with just drawing each character at a time if you're willing to lose kerning information. (We might want to add kerning metrics to TextMetrics, file a separate bug if you want that.) In short, I'm not really sure what to do here. See also comment 8.