[whatwg] Canvas lack of drawString method
Stefan Haustein
sh at kobjects.org
Mon Nov 6 13:06:23 PST 2006
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
>>>>
>>>>
>>>>
>>>
>>
>
>
More information about the whatwg
mailing list