- From: Stefan Haustein <sh@kobjects.org>
- Date: Mon, 06 Nov 2006 22:06:23 +0100
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