[whatwg] Still beating the drawString() dead horse...

[Stefan Haustein]

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