- From: Charles Iliya Krempeaux <supercanadian@gmail.com>
- Date: Wed, 25 Oct 2006 01:54:46 -0700
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>
Received on Wednesday, 25 October 2006 01:54:46 UTC