This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 14562 - According to the website, Canvas2D is one of the specifications that are on "last call", so here's what I'd still like to see (one graphics, two typographical, all three known irks for many people who actually use canvas): - an elliptical arc command in a
Summary: According to the website, Canvas2D is one of the specifications that are on "...
Status: RESOLVED INVALID
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML Canvas 2D Context (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-25 18:04 UTC by contributor
Modified: 2011-10-28 19:43 UTC (History)
7 users (show)

See Also:

Attachments

Description contributor 2011-10-25 18:04:28 UTC 
Specification: http://www.w3.org/TR/2dcontext/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
According to the website, Canvas2D is one of the specifications that are on
"last call", so here's what I'd still like to see (one graphics, two
typographical, all three known irks for many people who actually use canvas):

- an elliptical arc command in addition to the circular arc command. For nice
graphics, you need the elliptical arc, and a separate circular arc is a bonus
because you can perfectly reproduce a circle with an ellipse. As such, please
add an elliptical arc command to the API. It won't break work already done by
people so far, it's not a lot of work to implement for browser makers, and for
the end user it will offer a fast and correct arcing command, unlike
artificial solutions involving rolling your own approximation using bezier
curves or implementing the midpoint algorithm every time you need an
elliptical arc.

- a more elaborate font metrics object such as currently shimmer on
https://github.com/Pomax/fontmetrics.js so that graphics involving text that
has to interact with the canvas graphics (like every game that uses canvas2d,
for instance) stops being a headache. This also won't break work already done
by people so far, and will make life a lot easier for people who actually use
canvas. More importantly, it makes canvas more interesting for people who
currently forego canvas for things like flash because just text width is not
enough to work with text-as-graphics (something very different from working
with text).

- 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.

Yes, there are ways around all these limitations (obviously. any competent
HTML programmer can spend a day writing code that circumvent these gaps in the
Canvas2D API and end up with something that'll do the job, "until they add it
to the API"), but all of these involve highly artificial solutions that only
approximate the desired result, requiring lots of code to get to a result that
should only take a fraction of the time required if it were in API. Life can
still be made (lots) better for people who actually use Canvas2D.

Regards,

- Mike "Pomax" Kamermans
processing.js


N.B.: I am well aware of the difference between "text" and "text in a graphics
context". No, using overlay divs for text does not make sense, because you
can't blend that text into the graphics context. The intent is not to "place
text on the page", on top of a canvas, it's to use text as another graphics
primitive in a graphics context, giving us pixels that can be manipulated,
with corresponding metrics. Not "letters". Turning that text from "what we
specify" into "a completely different string" is not understanding the
difference between the page, and the graphics context. I am also well aware
that elliptical arcs can be approximated, which is nonsense when there is
already an API, and code in place in browsers, for circular arcs. The
extension to also having an elliptical arc is trivial, while offering a
essential graphics primitive.

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.202 Safari/535.1
Comment 1 Ian 'Hixie' Hickson 2011-10-26 23:20:08 UTC 
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: Rejected
Change Description: no spec change
Rationale: Please file only one issue per bug.

- I imagine we might add an ellipse feature in the future. What is your use case?

- TextMetrics improvements is bug 7798.

- I do not expect we will support multiline text on canvas. 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.
Comment 2 Jonas Sicking (Not reading bugmail) 2011-10-27 05:59:27 UTC 
(In reply to comment #1)
> 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: Rejected
> Change Description: no spec change
> Rationale: Please file only one issue per bug.
> 
> - I imagine we might add an ellipse feature in the future. What is your use
> case?
> 
> - I do not expect we will support multiline text on canvas. 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.

Based on comment #0, in both cases the use case is to implement a generic rendering library for a file format as a web application.

In this case the file format is processing.js

I would think that drawing an ellipse wouldn't be significantly less common than drawing a circle. Most drawing programs include them for example (which would be another use case).
Comment 3 Robert O'Callahan (Mozilla) 2011-10-27 06:32:36 UTC 
You can get an elliptical arc reasonably easily by drawing a circular arc while scaling in the x or y direction.
Comment 4 Robert O'Callahan (Mozilla) 2011-10-27 06:33:59 UTC 
I agree with Ian that this should be closed and bugs filed on individual issues.
Comment 5 Ian 'Hixie' Hickson 2011-10-28 19:43:53 UTC 
Unfortunately scaling leads to scaled line widths in one direction as well. I do think we'll eventually have to have native ellipse support.

If the other two issues are non-issues that aren't going to be escalated, I guess we can turn this into the placeholder bug for ellipse support (which I would then mark LATER for now), but I'd rather have a clean bug if that's ok. So I'm going to mark this one INVALID. Please do reopen the bug if you would rather see something here dealt with directly rather than a new bug opened.


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: Rejected
Change Description: no spec change
Rationale: see above