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 <[EMAIL PROTECTED]> 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
([EMAIL PROTECTED])
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