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>>
<br>> David Hyatt wrote:<br>> > I'm very reluctant to expose font metrics and information (yet). I<br>> > think once you start getting into specifying fonts, you open up<br>> a can<br>> > 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
<br>> font<br>> >>> object), I'd use a special parenthetical pseudo-element. thus<br>> >>> allowing the author to specify the style as for any other<br>> element on<br>> >>> 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>> >>>
<br>> >>> and letter-spacing/word-spacing would work, small-caps would<br>> work,<br>> >>> text-shadow would work, etc. etc.<br>> >>><br>> >>> 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
<br>> >>>>>> difficult to read<br>> >>>>>> - it needs to be specified whether css properties are inherited<br>> >>>>>> 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
<br>> >>>>>> it seems because of problems with internal data structures for<br>> >>>>>> rendering hints and implicitly introducing the ability to<br>> render<br>> >>>>>> the same element twice.
<br>> >>>>>> - what happens with contained plugins, canvas elements,<br>> >>>>>> self-references... all this stuff needs to be well-defined<br>> >>>>> 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
<br>> problem for<br>> >>>>>> non-browser environments such as Rhino.<br>> >>>>> How are we anticipating <canvas> might be used in a non-browser<br>> >>>>> 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>