W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2006

[whatwg] Canvas lack of drawString method

From: Mathieu Henri <p01@opera.com>
Date: Wed, 18 Oct 2006 21:27:34 +0200
Message-ID: <op.thmtn8bupgrbgq@id-c0279.oslo.opera.com>
On Wed, 18 Oct 2006 20:52:35 +0200, Gervase Markham <gerv at mozilla.org>  
wrote:

> Alfonso Baqueiro wrote:
>> The canvas component is very promising, but the lack of drawString  
>> method could be a great error for its success, this lack is a huge  
>> limitation, how could you resolve this problem?
>
> I've suggested this in the past as a solution to this problem: why not  
> have a drawElement(elem) parameter?
>
> That way, you could build an accessible, readable version of the content  
> inside the <canvas> tag, as alternative content, and copy labels or  
> anything else into the <canvas> itself with drawElement(label). So the  
> same content serves both as the accessible version and the used version.
>
> This would give us great flexibility, because the text you do have is  
> controlled with all the power of the existing CSS and browser font  
> model, obviating the need for font controls or font objects on the  
> <canvas> API - which would inevitably be not as good as the CSS ones.  
> And if browsers acquire downloadable font support, so does canvas.
>
> I would speculate wildly that it might even be easy to implement too.  
> After all, I'm sure browsers have the ability to render the contents of  
> a <div> tag to a drawing buffer...

Indeed, adding a something like the toDataURL( [MIMEType] ) method on the  
HTMLelement object would make our life so much easier and open a whole new  
range of possibilities.




-- 
Mathieu 'p01' HENRI
JavaScript developer, Opera Software ASA
Received on Wednesday, 18 October 2006 12:27:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:29 UTC