[whatwg] Canvas lack of drawString method

Stefan Haustein sh at kobjects.org
Wed Oct 25 03:04:10 PDT 2006


Hi Charles,

for bulk text, I think Canvas is the wrong place. However, if we get the 
metrics query methods, it would theoretically be possible to implement a 
renderer for any kind of specific purpose.

To display ruby annotations for labels (maps, some kind of educational 
flash-like application, you name it...), one could draw the annotation 
in a small font, aligned to the bottom and draw the base text aligned to 
the top (given the propsed alignment parameter is added):

canvas.textStyle = {"font-size": "5.5pt"};
canvas.drawString(100, 100, "ko ba ya shi", BOTTOM|HCENTER);
canvas.textStyle = {"font-size": "12pt"};
canvas.drawString(100, 100, "KO HAYASHI", TOP|HCENTER);

Best regards,
Stefan



Charles Iliya Krempeaux wrote:

> 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 
> <mailto: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>
>     > <mailto: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>
>     >     <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>
>     <mailto: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 <http://reptile.ca>
>     supercanadian @ gmail.com <http://gmail.com>
>
>     developer weblog: http://ChangeLog.ca/
>





More information about the whatwg mailing list