[whatwg] Canvas lack of drawString method

[David Hyatt]

I'm very reluctant to expose font metrics and information (yet).  I  
think once you start getting into specifying fonts, you open up a can  
of worms that would make this sort of API addition a lot harder.

dave

On Oct 24, 2006, at 4:05 PM, Stefan Haustein wrote:

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