[whatwg] Canvas lack of drawString method
hyatt at apple.com
Mon Oct 23 16:55:10 PDT 2006
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...
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.
(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
>>> - 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
>>> 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
> Canvas and some other parts of the spec (e.g. connections) may make
> 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,
More information about the whatwg