[whatwg] Canvas lack of drawString method

[Charles Iliya Krempeaux]

Hello Stefan,

(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.

On 10/25/06, Stefan Haustein <sh at kobjects.org> wrote:
>
> Charles Iliya Krempeaux wrote:
> > I believe it starts to gets more complex when you get into
> > globalization.  (Not that I'm an expert on that, but....)  More
> > thought may be needed to be put into this to make this work in a
> > global sense (and not just with roman-based alphabets like ours.)
> Hi Charles,
>
> what precisely are you suggesting? Are some characters missing from UTF?
> Are the writing direction properties of CSS not sufficient to cover some
> writing directions?
>
> To my knowledge concerning baseline/ascent/descent, non latin characters
> are equal (kyrillic, greek) or simpler, but of course I may be
> overlooking something, and I am always happy to learn anything new about
> I18N and foreign languages (if it is a bit more specific than "I belive
> there may be problems").
>
> Best regards,
> Stefan
>
>
> >
> > See ya
> >
> > On 10/25/06, *Stefan Haustein* <sh at kobjects.org
> > <mailto:sh at kobjects.org>> wrote:
> >
> >     Hi David,
> >
> >     of course adding only textStyle and drawText() is much better than
> >     nothing at all! :)
> >
> >     However, I would still prefer an API design that keeps it simple
> >     to add
> >     those methods later. Perhaps they could be included and simply
> return
> >     null if the requested information is not available (e.g. for a
> >     dumb EPS
> >     render target?). Also, if we do not have access to font metrics, I
> >     think
> >     we need an additional parameter for drawText() that specifies the
> >     alignment of the text relative to the reference point, as
> >     illustrated in
> >     the image below:
> >
> >     http://www.developer.com/img/articles/2002/12/26/03fig12.jpg
> >     <http://www.developer.com/img/articles/2002/12/26/03fig12.jpg>
> >
> >     Best regards,
> >     Stefan
> >
> >     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.
> >     >
> >     > dave
> >     >
> >     > On Oct 24, 2006, at 4:05 PM, Stefan Haustein wrote:
> >     >
> >     >> 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 <mailto: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
>



-- 
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20061025/c9165b3e/attachment.htm>