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* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> 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
> >>> ([EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>)
> >>>
> >>> 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/
