- From: Stefan Haustein <sh@kobjects.org>
- Date: Wed, 25 Oct 2006 12:04:10 +0200
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/
>
Received on Wednesday, 25 October 2006 03:04:10 UTC