Hello Stefan,<br><br>(Like I said, I'm not an expert on this, but....)  For a specific issue... One thing that comes to mind is "Ruby" in the Japanese language.<br><br><div><span class="gmail_quote">On 10/25/06, 

<b class="gmail_sendername">Stefan Haustein</b> <<a href="mailto:sh@kobjects.org">sh@kobjects.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Charles Iliya Krempeaux wrote:<br>> I believe it starts to gets more complex when you get into<br>> globalization.  (Not that I'm an expert on that, but....)  More<br>> thought may be needed to be put into this to make this work in a

<br>> global sense (and not just with roman-based alphabets like ours.)<br>Hi Charles,<br><br>what precisely are you suggesting? Are some characters missing from UTF?<br>Are the writing direction properties of CSS not sufficient to cover some

<br>writing directions?<br><br>To my knowledge concerning baseline/ascent/descent, non latin characters<br>are equal (kyrillic, greek) or simpler, but of course I may be<br>overlooking something, and I am always happy to learn anything new about

<br>I18N and foreign languages (if it is a bit more specific than "I belive<br>there may be problems").<br><br>Best regards,<br>Stefan<br><br><br>><br>> See ya<br>><br>> On 10/25/06, *Stefan Haustein* <

<a href="mailto:sh@kobjects.org">sh@kobjects.org</a><br>> <mailto:<a href="mailto:sh@kobjects.org">sh@kobjects.org</a>>> wrote:<br>><br>>     Hi David,<br>><br>>     of course adding only textStyle and drawText() is much better than

<br>>     nothing at all! :)<br>><br>>     However, I would still prefer an API design that keeps it simple<br>>     to add<br>>     those methods later. Perhaps they could be included and simply return<br>

>     null if the requested information is not available (e.g. for a<br>>     dumb EPS<br>>     render target?). Also, if we do not have access to font metrics, I<br>>     think<br>>     we need an additional parameter for drawText() that specifies the

<br>>     alignment of the text relative to the reference point, as<br>>     illustrated in<br>>     the image below:<br>><br>>     <a href="http://www.developer.com/img/articles/2002/12/26/03fig12.jpg">http://www.developer.com/img/articles/2002/12/26/03fig12.jpg

</a><br>>     <<a href="http://www.developer.com/img/articles/2002/12/26/03fig12.jpg">http://www.developer.com/img/articles/2002/12/26/03fig12.jpg</a>><br>><br>>     Best regards,<br>>     Stefan<br>>

>     David Hyatt wrote: >     > 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.

<br>>     ><br>>     > dave<br>>     ><br>>     > On Oct 24, 2006, at 4:05 PM, Stefan Haustein wrote:<br>>     ><br>>     >> Hi David,<br>>     >><br>>     >> I think it is very important to be able to determine the rendered

<br>>     >> size of the text. Otherwise, there is no reliable way to make sure<br>>     >> things do not overlap. Also, some kinds of applications (flash-like<br>>     >> effects, labels expressing weight or distance, WYSIWYG text

<br>>     editors)<br>>     >> may require variable font sizes or styles.<br>>     >><br>>     >> What do you think about<br>>     >><br>>     >> context.textStyle = "barchart"; // style by reference

<br>>     >><br>>     >> context.textStyle = {  // set style directly<br>>     >>  "font-size": "8px",<br>>     >>  "font-family": "Monaco, monospace"

<br>>     >> }<br>>     >><br>>     >> context.drawText(x,y,string); context.getFontAscent();<br>>     >> context.getFontDescent();<br>>     >> context.getFontLeading ();<br>>     >> 

context.getTextWidth(string);<br>>     >><br>>     >> Best regards,<br>>     >> Stefan<br>>     >><br>>     >><br>>     >><br>>     >><br>>     >><br>

>     >> David Hyatt wrote:<br>>     >>> I think a drawText method would be extremely useful.<br>>     >>><br>>     >>> 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...

<br>>     >>><br>>     >>> canvas::canvas-text(barchart)<br>>     >>> {<br>>     >>>     font-size: 8px;<br>>     >>>     font-family: Monaco, monospace;<br>>     >>> }

<br>>     >>><br>>     >>> and then the API would be something like:<br>>     >>><br>>     >>> drawText(y-coord of baseline, "barchart", myText)<br>>     >>>

>     >>> and letter-spacing/word-spacing would work, small-caps would >     work, >     >>> text-shadow would work, etc. etc. >     >>> >     >>> fitTextToPath might be an interesting API too.

<br>>     >>><br>>     >>> dave<br>>     >>> (<a href="mailto:hyatt@apple.com">hyatt@apple.com</a> <mailto:<a href="mailto:hyatt@apple.com">hyatt@apple.com</a>>)<br>>     >>>

<br>>     >>> On Oct 23, 2006, at 4:07 PM, Stefan Haustein wrote:<br>>     >>><br>>     >>>> Gervase Markham wrote:<br>>     >>>>> Stefan Haustein wrote:<br>>     >>>>>> I think drawElement(elem) opens up a whole new can of worms:

<br>>     >>>>>><br>>     >>>>>> - how would an application determine the size of the text box?<br>>     >>>>>> - where is the baseline position, needed for exact axis label

<br>>     >>>>>> positioning?<br>>     >>>>>> - there are probably issues with dynamically calculated<br>>     text values<br>>     >>>>>> - 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".

<br>>     >>>>>> - how much horizontal/vertical space is drawElement<br>>     permitted to<br>>     >>>>>> use for rendering?<br>>     >>>>> The answer to all of these things is that the browser

<br>>     renders all<br>>     >>>>> the elements in the page as it would if the <canvas> were not<br>>     >>>>> supported and the alternate content were being used. It then<br>

>     >>>>> basically screenshots the area corresponding to the element<br>>     (yes,<br>>     >>>>> I know this needs careful definition) and draws that into<br>>     the canvas.

<br>>     >>>> I do not see how your statement answers any of my questions<br>>     except<br>>     >>>> from the last one. You can specify some CSS constraints, but<br>>     how do<br>

>     >>>> you determine the actual rendering height of a text box with a<br>>     >>>> specific width? How do you determine the pixel position of the<br>>     >>>> baseline? The cross reference and the dynamic text issues are not

<br>>     >>>> addressed at all.<br>>     >>>>> Like I said, we want to leverage the browser's deep and complex<br>>     >>>>> knowledge of text rendering as much as possible, and just

<br>>     take the<br>>     >>>>> resulting pixel output as it would be shown to the user.<br>>     >>>>>> - the implementation in actual browsers may be more complex<br>>     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.

<br>>     But we<br>>     >>>>> could put limits on it like e.g. no plugins, no <object>, and<br>>     >>>>> still have something very useful for rendering text.<br>>     >>>> So I assume we agree that the element rendering proposal would

<br>>     >>>> still need significant specification work and is probably<br>>     much more<br>>     >>>> difficult to implement. The element rendering approach may make<br>>     >>>> working with bulk text simpler, but this case is already handled

<br>>     >>>> quite fine by HTML outside the Canvas element. By asking for too<br>>     >>>> much, we may end up with nothing at all.<br>>     >>>><br>>     >>>> Andrew has provided a clear and simple proposal that can

<br>>     easily be<br>>     >>>> implemented without too much consideration of side effects.<br>>     Putting<br>>     >>>> labels on maps, precise text positioning, starwars-like 3d<br>

>     >>>> scrolling text, labels for game characters or in physics<br>>     >>>> simulations, all the stuff that could only be done in a canvas<br>>     >>>> element, is trivial to implement with the drawText()

<br>>     approach, but<br>>     >>>> seems much more complex or impossible with the element rendering<br>>     >>>> approach.<br>>     >>>>>> 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?

<br>>     >>>> Canvas and some other parts of the spec (e.g. connections)<br>>     may make<br>>     >>>> a lot of sense for Javascript outside of the browser<br>>     context.  This<br>

>     >>>> may be outside of the scope of WHATWG, but if we can take out<br>>     some<br>>     >>>> building blocks and use them somewhere else, this is at least a<br>>     >>>> sign of good and modular API design.

<br>>     >>>><br>>     >>>> Best regards,<br>>     >>>> Stefan<br></blockquote></div><br><br clear="all"><br>-- <br>    Charles Iliya Krempeaux, B.Sc.<br><br>    charles @ <a href="http://reptile.ca">

reptile.ca</a><br>    supercanadian @ <a href="http://gmail.com">gmail.com</a><br><br>    developer weblog: <a href="http://ChangeLog.ca/">http://ChangeLog.ca/</a><br><br>