[whatwg] Canvas lack of drawString method

[David Hyatt]

I think a drawText method would be extremely useful.

Rather than specifying stylistic information explicitly (via a font  
object), I'd use a special parenthetical pseudo-element. thus  
allowing the author to specify the style as for any other element on  
a page.... something like this...

canvas::canvas-text(barchart)
{
	font-size: 8px;
	font-family: Monaco, monospace;
}

and then the API would be something like:

drawText(y-coord of baseline, "barchart", myText)

and letter-spacing/word-spacing would work, small-caps would work,  
text-shadow would work, etc. etc.

fitTextToPath might be an interesting API too.

dave
(hyatt at apple.com)

On Oct 23, 2006, at 4:07 PM, Stefan Haustein wrote:

> Gervase Markham wrote:
>> Stefan Haustein wrote:
>>> I think drawElement(elem) opens up a whole new can of worms:
>>>
>>> - how would an application determine the size of the text box?
>>> - where is the baseline position, needed for exact axis label  
>>> positioning?
>>> - there are probably issues with dynamically calculated text values
>>> - code with lots of cross references to elements will be  
>>> difficult to read
>>> - it needs to be specified whether css properties are inherited  
>>> from the parent element of "elem".
>>> - how much horizontal/vertical space is drawElement permitted to  
>>> use for rendering?
>> The answer to all of these things is that the browser renders all  
>> the elements in the page as it would if the <canvas> were not  
>> supported and the alternate content were being used. It then  
>> basically screenshots the area corresponding to the element (yes,  
>> I know this needs careful definition) and draws that into the canvas.
> I do not see how your statement answers any of my questions except  
> from the last one. You can specify some CSS constraints, but how do  
> you determine the actual rendering height of a text box with a  
> specific width? How do you determine the pixel position of the  
> baseline? The cross reference and the dynamic text issues are not  
> addressed at all.
>> Like I said, we want to leverage the browser's deep and complex  
>> knowledge of text rendering as much as possible, and just take the  
>> resulting pixel output as it would be shown to the user.
>>> - the implementation in actual browsers may be more complex than  
>>> it seems because of problems with internal data structures for  
>>> rendering hints and implicitly introducing the ability to render  
>>> the same element twice.
>>> - what happens with contained plugins, canvas elements, self- 
>>> references... all this stuff needs to be well-defined
>> Indeed. I know it's easy to state and there are edge cases. But we  
>> could put limits on it like e.g. no plugins, no <object>, and  
>> still have something very useful for rendering text.
> So I assume we agree that the element rendering proposal would  
> still need significant specification work and is probably much more  
> difficult to implement. The element rendering approach may make  
> working with bulk text simpler, but this case is already handled  
> quite fine by HTML outside the Canvas element. By asking for too  
> much, we may end up with nothing at all.
>
> Andrew has provided a clear and simple proposal that can easily be  
> implemented without too much consideration of side effects. Putting  
> labels on maps, precise text positioning, starwars-like 3d  
> scrolling text, labels for game characters or in physics  
> simulations, all the stuff that could only be done in a canvas  
> element, is trivial to implement with the drawText() approach, but  
> seems much more complex or impossible with the element rendering  
> approach.
>>> Moreover, drawElement() would not solve the drawText problem for  
>>> non-browser environments such as Rhino.
>> How are we anticipating <canvas> might be used in a non-browser  
>> context?
> Canvas and some other parts of the spec (e.g. connections) may make  
> a lot of sense for Javascript outside of the browser context.  This  
> may be outside of the scope of WHATWG, but if we can take out some  
> building blocks and use them somewhere else, this is at least a  
> sign of good and modular API design.
>
> Best regards,
> Stefan
>
>
>