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

Mathieu HENRI 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.
>
> I still think by introducing the drawString() method into Canvas we 
> are opening the same can of worms that was open in SVG.
> If we go that way we will need a drawParagraph() method to draw multi 
> line strings or blocks of text with wrapping and a bounding width. We 
> also need to be able to stylize the text, i.e. changing the 
> font-weight / color / font-style ... of any word.
Hi Mathieu,

I do no see how adding drawString() implies that drawParagraph() must be 
added, too. In fact, you can implement all that stuff yourself in 
Javascript in a way that suits your application data.

Comparing SVG and Canvas is like comparing apples and oranges. Instead 
of comparing Canvas to a declarative approach, why not compare it to the 
Java Canvas class? Java 1.1 did not have any drawParagraph() method, 
only drawString(), but you could still implement a whole text editor.

 > The list goes on and on ... and HTML and CSS already cover it all.

HTML and CSS do not cover access to the font metrics. If HTML and CSS 
are suitable for your use case, why not stick with HTML and CSS in the 
first place? What is the use case for drawElement()?

For applications such as labels in dynamic maps, graphs, game scores and 
data visualization, drawElement() simply does not seem adequate.
> The HTMLElement.drawElement() method should be no problem to implement 
> since userAgents already do render HTMLElements.
Being able to tender HTML elements does not imply that it is simple to 
render HTML elements out of context or multiple times. Even if it may be 
simple in one particular browser implementation, that does not imply 
that it is simple in others.
> Having it return an ImageData object will make it insanely simple to 
> manipulate in Canvas. 
Memory usage and slowness will also become insane, and upscaling will 
become insanely ugly.
> The text elements/contents can easily be in the fall back content of 
> the Canvas tag thus keeping it accessible. 
If the text is usable on its own, it is probably better placed in 
regular HTML content.
> Getting the bounding box of an HTMLElement is no problem either in 
> JavaScript. And applying gradients and patterns can be done using a 
> fillRect() with the appropriate globalCompositeOperation.
The bounding box does not help to align a the beaseline of a label with 
a given coordinate.
> Everything (almost) is there. Let's not re-invent a square wheele
The problem here is "almost".  All other graphics libraries seem to roll 
fine with this "square wheel", so perhaps it is a bit rounder than you 
suggest? No, SVG is not  a graphics library....

Best regards,
Stefan

Received on Tuesday, 14 November 2006 05:09:32 UTC