[whatwg] Canvas lack of drawString method

Hi Joao,

the Canvas API is already using CSS-like color definitions, so any 
Canvas API implementation is already forced to implement some small bits 
of CSS. It would be just consistent to describe a font request in a 
similar way. Not using CSS names and values for describing font 
properties would mean to re-invent the wheel. Why should I learn new 
names for font properties if I could simply use the ones I already know 
from CSS?

Of course, in a non-browser environment, one would not be able to assign 
a style by reference to a style sheet.

I have implemented most of the Canavas API for the Rhino Javascript 
interpreter (significant omissions are darker, lighter and arcTo), so if 
you are interested in non-browser Canvas API stuff, you may want to take 
a look at http://rhino-canvas.sf.net

I did not include any kind of drawString() yet -- I am still hoping for 
some kind of consensus on the list... :)

Best regards,
Stefan


Concerning

Joao Eiras wrote:
> I think mixing CSS and Canvas is a bad idea.
> You could develop an application which would implement the canvas APi, 
> and be easily programed with ecmascript or java.
> Adding this kind of feature would force the implementor to support CSS 
> too, at least partially.
>
>
> Stefan Haustein <sh at kobjects.org> escreveu:
>
>> Hi David,
>>
>> I think it is very important to be able to determine the rendered 
>> size of the text. Otherwise, there is no reliable way to make sure 
>> things do not overlap. Also, some kinds of applications (flash-like 
>> effects, labels expressing weight or distance, WYSIWYG text editors) 
>> may require variable font sizes or styles.
>>
>> What do you think about
>>
>> context.textStyle = "barchart"; // style by reference
>>
>> context.textStyle = {  // set style directly
>>   "font-size": "8px",
>>   "font-family": "Monaco, monospace"
>> }
>>
>> context.drawText(x,y,string); context.getFontAscent();
>> context.getFontDescent();
>> context.getFontLeading();
>> context.getTextWidth(string);
>>
>> Best regards,
>> Stefan
>>
>>
>>
>>
>>
>> David Hyatt wrote:
>>> 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
>>>>
>>>>
>>>>
>>>
>>
>
>

Received on Monday, 6 November 2006 13:06:23 UTC