Hi Martin,
the problem is that we need to draw the line somewhere. In my opinion,
stuff that can be implemented in Javascript on top of the API should not
go into the core API, because there are so many different ways to do it.
For instance, what shall the implementation do if the text does not fix
in the box? An alternative may be to have only a width parameter and
return the rendered height, but then the next logical step is to ask for
the calculation without the rendering....
drawString() has a clear and simple use case: Labels (e.g. in Maps) and
calculated values (scores, numbers, ...).
Everything beyond is a separate use case that should be discussed
separately. I think the main problem here is that drawElement() was
suggested as a kind of replacement for drawString(), but it is actually
something completely different, that should be discussed separately.
drawElement() does not really remove the need for a simple API. I feel
like asking for a scissor, but being told that a combine harvester is
much more powerfull... That may be true, but it is also a bit
unpractical, lets say for something like a hair cut.
Best regards,
Stefan
Martin Atkins wrote:
Stefan Haustein wrote:
Hi,
I have tried to sum up the requirements for
CanvasRenderingContext2D.drawString() at
http://rhino-canvas.sf.net/www/drawstring.html
The page contains an API proposal based on the Font/TextStyle object
approach that
meets all those requirements, and also some motivation why I have
implemented this
approach and not one of the alternatives discussed here.
Some comments:
--------------------
void drawString(in float x, in float y, in DOMString text);
...
attribute DOMString verticalAlign;
attribute DOMString textAlign;
I'm guessing from the function signature that what is actually
changing here is how the coordinates (x,y) relate to the rendered
text. a textAlign of right will presumably cause the text to be drawn
with the rightmost edge at x.
However, it'd also be useful to be able to render formatted blocks of
text, like this:
void drawString(in float x1, in float y1, in float x2, in float y2,
in DOMString text)
...which wrap text and would make a textAlign of "justify" meaningful.
Suddenly a bunch more CSS properties become attractive (margins and
letter spacing, for example) but I think line-height alone would do
for now.
Rendering formatted blocks of text seems to me to be such a common
thing that the canvas API should support it natively.
This does, of course, require more functions on TextStyle to measure
the extent of a block of text. This could probably be confined to just
the following:
float getBlockHeight(in DOMString s, float width)
--------------------
I think that a good use-case for this would be replacing regular
document elements with canvases, either using bare script or using
XBL. You point out in your document that drawElement(e) is tricky, but
for limited cases it would be nice to be able to obtain the computed
style of the canvas element to use for rendering, so that the text can
match the style of the surrounding document.
This can be as simple as one method on the canvas context to fetch the
computed style, which would presumably return null in a non-browser
implementation of the API.
CanvasTextStyle getInheritedStyle();
For example, this could be used to create some kind of visual effect
(fancy headings?) or to render a graphical element from some XML
namespace that isn't supported in browsers yet.
