This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In order to properly replace text to support rich text editing it is important that we be able to ascertain the baseline position of text in order to perform proper text placement. Consequently it is essential that 'baseline' be added to the TextMetrics object returned from .measureText. We recommend returning the float y-offset the baseline will be set at from the origin based on the current value of textBaseline, font and the content of the measureText DOMString argument.
Which baseline? And why do you need this through the metrics mechanism rather than the rendering mechanism (where it is already available)? If you could provide a simple page with a canvas script showing the problem that would be ideal.
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: See comment 1.
Bug triage sub-team assigning to Rich Schwerdtfeger to provide the requested info.
One can not surround inline text with a focus ring as is done with a focusable [span], using Canvas, as the baseline information is not shared, only the width. This defect inhibits text decorations, highlighting, and drawFocusRing. The baseline value is valuable for aligning text of different font sizes or styles, as well as annotating text with indicators. Such flexibility is generally why Canvas is used in the first place. As for focus rings, that is part of the work here, and baseline would allow Canvas the same accuracy of drawFocusRing as span currently does.
That doesn't answer the question in comment 1. Which baseline? Could you provide a sample canvas script showing the problem?
(In reply to comment #5) > That doesn't answer the question in comment 1. Which baseline? Could you > provide a sample canvas script showing the problem? My thinking was just to provide the baseline offset based on the current setting of textBaseline. Usually, I'd grab the descent, based on alphabetic and bottom (or top) metrics. Here's an example script -- very hackish, but it shows an adjusted baseline being used with the outline made via strokeRect. (I used CSS hacks to pull the data): http://dl.dropbox.com/u/17337752/text-legibility-script.html Were baseline information available, based on the setting of textBaseline, an various baseline metrics could be pulled by switching textBaseline then running measureText for each value (top, bottom, etc). An image similar to the following could be generated; though that's not a primary use case. http://www.whatwg.org/specs/web-apps/current-work/images/baselines.png
Aah, so basically you need the distance from the current textBaseline to each of the possible baselines, for a particular span of text. Hmm. That's actually somewhat non-trivial to define, since a single string can have multiple distances for each baseline (that's why we need to provide a way to align to each baseline to start with).
(In reply to comment #7) > Aah, so basically you need the distance from the current textBaseline to each > of the possible baselines, for a particular span of text. > Hmm. > That's actually somewhat non-trivial to define, since a single string can have > multiple distances for each baseline (that's why we need to provide a way to > align to each baseline to start with). You've got it. When you say "non-trivial to define", are you referring to defining it in the specs, or are you talking about actual implementation? As for the specs, I think it's self-contained. It'd return the calculated baseline for the content passed through measureText given the current textBaseline. For implementation, you're absolutely correct: a single string may rely upon multiple fonts; especially a multilingual string. I'm all-but-certain, though, that those cases are handled by underlying font layout engines. If the font engine is inaccurate/strange, that's perfectly fine... we don't need to define what "bottom" means in the spec, merely that the measureText baseline attribute returns whatever the font engine has calculated.
I meant both for specs and implementations. It's more or less the same problem either way. 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: Since this is a new feature request, I'm marking this LATER for the time being. This, as well as a number of other TextMetric issues such as the proposal in bug 7798, are likely to be the first things we add to the canvas API when we next add features to the canvas API. In the meantime, we really need to wait for implementations to catch up with what's been specified so far.
(In reply to comment #9) > I meant both for specs and implementations. It's more or less the same problem > either way. > Would two implementations fulfill requirements to have this added to the spec? It's a very simple issue in implementations, as the code is already available from textBaseline and/or fillText setters and methods. I don't see the difficulty in writing wording for this, for the spec. I'll write up patches and a spec wording submitted in the near future, and re-open this issue.
See bug report 11239 for a reference to source code to make this change on April 13 by Charles Pritchard
mass-move component to LC1
Ian, I was asked by the accessibility task force to make this a tracker request. This pertains to Issue 131. Here is a link the request to the chairs and the change proposal: http://lists.w3.org/Archives/Public/public-html-a11y/2012Jan/0087.html
Proposed wording for tracker issue: canvas-text-baseline: Modify existing Canvas 2D API to expose text baseline and facilitate drawing of focus rings There is an existing change proposal for this: http://www.w3.org/html/wg/wiki/ChangeProposals/FocusRingTextBaseline
Added to http://www.w3.org/html/wg/tracker/issues/131
Reclosing since this is marked TrackerIssue. I'm tracking this as part of bug 7798.
Comment via Rich Schwerdtfeger: This does not appear to have been addressed by the chairs. We have focus rings functions but it would be valuable to have this addition to text metrics in order to compute the path for drawing the focus rings. At one point they had asked for additional information and it was provided. http://www.w3.org/html/wg/wiki/ChangeProposals/FocusRingTextBaseline
(In reply to comment #17) > Comment via Rich Schwerdtfeger: > > This does not appear to have been addressed by the chairs. We have focus > rings functions but it would be valuable to have this addition to text > metrics in order to compute the path for drawing the focus rings. At one > point they had asked for additional information and it was provided. > > http://www.w3.org/html/wg/wiki/ChangeProposals/FocusRingTextBaseline The current textmetrics API returns a set of baselines. Does this API not fulfill your use=case?
There hasn't been a reply to Rik's question. There is a selection of baselines for TextMetrics that were added for the CR, and the question is whether they cover what is being asked. If no reply is made in 7 days, I'll resolve this as won't fix.
Yes, the new API covers the use case. (In reply to comment #19) > There hasn't been a reply to Rik's question. There is a selection of > baselines for TextMetrics that were added for the CR, and the question is > whether they cover what is being asked. > > If no reply is made in 7 days, I'll resolve this as won't fix.
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: Won't Fix Change Description: none yet Rationale: The request here duplicates or describes the current behavior of the TextMetrics object and attributes.
Reopened for discussion and assigning to Canvas 2D Context level 2
It appears this is covered in the L2 spec.
Apparently works for the people who need it.