Re: [whatwg] Canvas lack of drawString method
Hi Joao,
the Canvas API is already using CSS-like color definitions, so any
Canvas API implementation is already forced to implement some small bits
of CSS. It would be just consistent to describe a font request in a
similar way. Not using CSS names and values for describing font
properties would mean to re-invent the wheel. Why should I learn new
names for font properties if I could simply use the ones I already know
from CSS?
Of course, in a non-browser environment, one would not be able to assign
a style by reference to a style sheet.
I have implemented most of the Canavas API for the Rhino Javascript
interpreter (significant omissions are darker, lighter and arcTo), so if
you are interested in non-browser Canvas API stuff, you may want to take
a look at http://rhino-canvas.sf.net
I did not include any kind of drawString() yet -- I am still hoping for
some kind of consensus on the list... :)
Best regards,
Stefan
Concerning
Joao Eiras wrote:
I think mixing CSS and Canvas is a bad idea.
You could develop an application which would implement the canvas APi,
and be easily programed with ecmascript or java.
Adding this kind of feature would force the implementor to support CSS
too, at least partially.
Stefan Haustein [EMAIL PROTECTED] escreveu:
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])
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
Re: [whatwg] Canvas lack of drawString method
I think mixing CSS and Canvas is a bad idea.
You could develop an application which would implement the canvas APi, and
be easily programed with ecmascript or java.
Adding this kind of feature would force the implementor to support CSS
too, at least partially.
Stefan Haustein [EMAIL PROTECTED] escreveu:
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])
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
Re: [whatwg] Canvas lack of drawString method
dolphinling wrote: What if the canvas and span are surrounded by something with font-weight:bold? Will the text in the canvas be drawn bold, too? It's the responsibility of the page designer to make sure the text they are measuring is styled the same as the text they want the metrics of. According to the current API suggestion, the styling of the text in a canvas will not be affected by the style of parent elements, but will be defined by the style of the pseudo element name passed to the drawText function. Gerv
Re: [whatwg] Canvas lack of drawString method (p.s.)
p.s.: However, I would still prefer an API design that keeps it simple to add those methods later. ^ those = the metrics query methods, of course Deleted some text block and then it became a bit out of context
Re: [whatwg] Canvas lack of drawString method
Hello,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.)
See yaOn 10/25/06, Stefan Haustein [EMAIL PROTECTED] wrote:
Hi David,of course adding only textStyle and drawText() is much better thannothing at all! :)However, I would still prefer an API design that keeps it simple to addthose methods later. Perhaps they could be included and simply return
null if the requested information is not available (e.g. for a dumb EPSrender target?). Also, if we do not have access to font metrics, I thinkwe need an additional parameter for drawText() that specifies the
alignment of the text relative to the reference point, as illustrated inthe image below:http://www.developer.com/img/articles/2002/12/26/03fig12.jpg
Best regards,StefanDavid 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 directlyfont-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]
) 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
Re: [whatwg] Canvas lack of drawString method
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] 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
([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
Re: [whatwg] Canvas lack of drawString method
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] 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 charactersare equal (kyrillic, greek) or simpler, but of course I may beoverlooking something, and I am always happy to learn anything new about
I18N and foreign languages (if it is a bit more specific than I belivethere may be problems).Best regards,Stefan See ya On 10/25/06, *Stefan Haustein*
[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 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])
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
Re: [whatwg] Canvas lack of drawString method
Stefan Haustein wrote: I think it is very important to be able to determine the rendered size of the text. Can't you determine the size from the accessible version you are doubtless creating inside the canvas element? ;-) (This assumes that if you draw a string in 8px Monaco on a canvas, and do the same thing in a span, the span will have the same size as the canvas version. But that seems to make sense to me.) context.drawText(x,y,string); context.getFontAscent(); context.getFontDescent(); context.getFontLeading(); Hang on; can we even get these for existing text styled with CSS in web pages? Gerv
Re: [whatwg] Canvas lack of drawString method
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. I still believe that any api that does not allow the author to query the size of the text bounding-box[1], i.e. the overall width and height of the box enclosing the text fragment, is useless for many of the use cases presented so far e.g. figure labelling as, without this information, it is impossible to ensure that adjacent text fragments do not overlap. [1] I mean that in a non-technical sense -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] Canvas lack of drawString method
Yeah I see what you mean. In addition to a drawText you probably want something like a metricsForText API that would tell you the extent of the string and the font metrics (line height, ascent, descent, baseline). dave On Oct 25, 2006, at 3:10 AM, James Graham wrote: 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. I still believe that any api that does not allow the author to query the size of the text bounding-box[1], i.e. the overall width and height of the box enclosing the text fragment, is useless for many of the use cases presented so far e.g. figure labelling as, without this information, it is impossible to ensure that adjacent text fragments do not overlap. [1] I mean that in a non-technical sense -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] Canvas lack of drawString method
Gervase Markham wrote: Stefan Haustein wrote: I think it is very important to be able to determine the rendered size of the text. Can't you determine the size from the accessible version you are doubtless creating inside the canvas element? ;-) (This assumes that if you draw a string in 8px Monaco on a canvas, and do the same thing in a span, the span will have the same size as the canvas version. But that seems to make sense to me.) What if the canvas and span are surrounded by something with font-weight:bold? Will the text in the canvas be drawn bold, too? -- dolphinling http://dolphinling.net/
Re: [whatwg] Canvas lack of drawString method
David Hyatt wrote: and then the API would be something like: drawText(y-coord of baseline, barchart, myText) I like this idea :-) At the risk of overcomplicating, vertical text is a common requirement for graphs and charts. If this is simpler to implement than the arbitrary text rotation case, is it worth having a way of saying the baseline is vertical rather than horizontal? Or would this be a job for fitTextToPath()? Gerv
Re: [whatwg] Canvas lack of drawString method
Alfonso Baqueiro wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? Just for a bit of fun, I created a demo to show how it is already possible to render text on canvas. This technique has certainly got many limitations and could never be made as good as a native implementation, but it works Firefox, Opera and Safari. http://lachy.id.au/dev/2006/10/canvas-text -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Canvas lack of drawString method
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])
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
Re: [whatwg] Canvas lack of drawString method
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
Re: [whatwg] Canvas lack of drawString method
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])
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
Re: [whatwg] Canvas lack of drawString method
Hi Andrew, I agree that the structure of your proposal is better, the Font object is not really needed. However, I think getAscent() is not sufficient, we should also add getLeading() and getDescent(): This would allow us to determine the total line height (leading+ascent+descent) and the baseline position (leading+ascent): http://docs.rinet.ru/UJ11/art/17/17fig08n.jpg The total line height is important since it constitutes the minimum vertical distance from baseline to baseline (Accents on uppercase letters will be placed in the leading area, and they must not overlap with the descent from the previous line). The baseline position is important for text alignment when using different fonts/styles in a single line. Of course we, could add getBaselinePosition() and getHeight() instead of some of the other methods, but including the three most basic values seems to be a consistent approach (simple to remember) and all other values can be calculated by summing them up somehow (no differences needed). Best regards, Stefan Andrew Fedoniouk wrote: - Original Message - From: Stefan Haustein [EMAIL PROTECTED] Cc: WHAT Working Group Mailing List [EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 2:50 PM Subject: Re: [whatwg] Canvas lack of drawString method Hi, I would like to second the drawString() request. It makes sense to have a simple API, but it should be balanced with application simplicity and readability to some extent. Doing CSS black magic to overlay text and a Canvas object just seems inadequate for something like axis labeling. As noted earlier by somebody else (did not find the mail...), we would also need a simple Font object, but the minimum requirements seem rather simple: Font Canvas.createFont(String cssFontProperties); Canvas.setFont(Font font) // set current font Canvas.drawString(int x, int y, String text); Font Canvas.getFont() // current font int Font.stringWidth(String s); int Font.getHeight(); // includes leading int Font.getBaselinePosition(); int Font.getAscent(); int Font.getDescent(); In fact separate Font object is not needed in most cases. It is enough to have simple setFont function for that. I've found that following five methods of Graphics are just enough: Graphics.setFont(FontOrFamilyName, size, weight, ...); Graphics.setTextAlignment(horizontal, vertical); Graphics.getFontAscent(); Graphics.getTextWidth(string); Graphics.drawText(x,y,string); For example, below is code fragment drawing this: http://www.terrainformatica.com/sciter/screenshots/sciter-graphics-text.jpg var gfx = sandbox.graphics(#v2d); var width = sandbox.box(#width); var height = sandbox.box(#height); gfx.lineWidth(1.0); gfx.lineJoin = Graphics.JOIN_ROUND; gfx.lineColor(Graphics.RGBA(0x7F,0,0)); gfx.fillRadialGradient(width/2, height/2, height/2, Graphics.RGBA(0xFF,0xFF,0), Graphics.RGBA(0xFF,0,0) ); gfx.setTextAlignment(Graphics.ALIGN_CENTER,Graphics.ALIGN_CENTER); gfx.setFont(Verdana, 64.0); gfx.text(width/2, height/2, Text in Sciter!); --- drawText shall use outline and fill attributes that Graphics already has. It also shall follow all transformation attributes. It is highly non desirable to have separate objects like brushes and fonts with non-deterministic life span. Especially in GC environments. Andrew Fedoniouk. http://terrainformatica.com Best regards Stefan Haustein Alfonso Baqueiro wrote: Hello Charles, 2006/10/17, Charles Iliya Krempeaux [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hello Alfonso, On 10/17/06, *Alfonso Baqueiro* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? I believe that some people's reason for not wanting to add it was because of Accessibility concerns. Although normal text in a webpage... or even a text image (with the alt attribute filled in properly) could be read by a person with disabilities, text embedded in the canvas element could not. Perhaps people need to think about how to add Accessibility to the canvas while allowing a drawString procedure. Well a drawString method in canvas can be used for drawing the axis labels or values on a dinamic javascript graphic, but is non sense an aural reader read it, theres no way (yet) to read an image to a blinded people, there are cases where is imposible the accessibility, is imposible for a blind to play video games, and accessibility dont stop the video games creation. In the case of images or the canvas the alt attribute could do the job. See ya
Re: [whatwg] Canvas lack of drawString method
Alfonso Baqueiro wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? I've suggested this in the past as a solution to this problem: why not have a drawElement(elem) parameter? That way, you could build an accessible, readable version of the content inside the canvas tag, as alternative content, and copy labels or anything else into the canvas itself with drawElement(label). So the same content serves both as the accessible version and the used version. This would give us great flexibility, because the text you do have is controlled with all the power of the existing CSS and browser font model, obviating the need for font controls or font objects on the canvas API - which would inevitably be not as good as the CSS ones. And if browsers acquire downloadable font support, so does canvas. I would speculate wildly that it might even be easy to implement too. After all, I'm sure browsers have the ability to render the contents of a div tag to a drawing buffer... Gerv
Re: [whatwg] Canvas lack of drawString method
On Wed, 18 Oct 2006 20:52:35 +0200, Gervase Markham [EMAIL PROTECTED] wrote: Alfonso Baqueiro wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? I've suggested this in the past as a solution to this problem: why not have a drawElement(elem) parameter? That way, you could build an accessible, readable version of the content inside the canvas tag, as alternative content, and copy labels or anything else into the canvas itself with drawElement(label). So the same content serves both as the accessible version and the used version. This would give us great flexibility, because the text you do have is controlled with all the power of the existing CSS and browser font model, obviating the need for font controls or font objects on the canvas API - which would inevitably be not as good as the CSS ones. And if browsers acquire downloadable font support, so does canvas. I would speculate wildly that it might even be easy to implement too. After all, I'm sure browsers have the ability to render the contents of a div tag to a drawing buffer... Indeed, adding a something like the toDataURL( [MIMEType] ) method on the HTMLelement object would make our life so much easier and open a whole new range of possibilities. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] Canvas lack of drawString method
Hello Alfonso,On 10/17/06, Alfonso Baqueiro [EMAIL PROTECTED] wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? I believe that some people's reason for not wanting to add it was because of Accessibility concerns. Although normal text in a webpage... or even a text image (with the alt attribute filled in properly) could be read by a person with disabilities, text embedded in the canvas element could not. Perhaps people need to think about how to add Accessibility to the canvas while allowing a drawString procedure. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/___ Make Televisionhttp://maketelevision.com/ ___ Cars, Motorcycles, Trucks, and Racing... http://tirebiterz.com/
Re: [whatwg] Canvas lack of drawString method
On Tue, 17 Oct 2006 20:16:33 +0200, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Hello Alfonso, On 10/17/06, Alfonso Baqueiro [EMAIL PROTECTED] wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? Canvas does have text capabilities for the sake of simplicity. Add drawString and then you need stringOnPath, clipping, styling of the texts, multiline strings, full support of unicode, ... and then you end up with a programmatic only version of SVG. I believe that some people's reason for not wanting to add it was because of Accessibility concerns. But if a user agent do no support Canvas, it MUST fallback to the descendant tags of the Canvas. There you have the accessibility mean. Although normal text in a webpage... or even a text image (with the alt attribute filled in properly) could be read by a person with disabilities, text embedded in the canvas element could not. Perhaps people need to think about how to add Accessibility to the canvas while allowing a drawString procedure. It would easy to use DOM methods to grab the texts to display in the fallback content of the Canvas tag. Provided that the fallback markup is exposed to JavaScript in the user agents that support Canvas. -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] Canvas lack of drawString method
Hello Charles,2006/10/17, Charles Iliya Krempeaux [EMAIL PROTECTED]: Hello Alfonso,On 10/17/06, Alfonso Baqueiro [EMAIL PROTECTED] wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? I believe that some people's reason for not wanting to add it was because of Accessibility concerns. Although normal text in a webpage... or even a text image (with the alt attribute filled in properly) could be read by a person with disabilities, text embedded in the canvas element could not. Perhaps people need to think about how to add Accessibility to the canvas while allowing a drawString procedure.Well a drawString method in canvas can be used for drawing the axis labels or values on a dinamic _javascript_ graphic, but is non sense an aural reader read it, theres no way (yet) to read an image to a blinded people, there are cases where is imposible the accessibility, is imposible for a blind to play video games, and accessibility dont stop the video games creation. In the case of images or the canvas the alt attribute could do the job. See ya
Re: [whatwg] Canvas lack of drawString method
On Tue, 17 Oct 2006 20:32:11 +0200, Mathieu Henri [EMAIL PROTECTED] wrote: On Tue, 17 Oct 2006 20:16:33 +0200, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Hello Alfonso, On 10/17/06, Alfonso Baqueiro [EMAIL PROTECTED] wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? Canvas does have text capabilities for the sake of simplicity. Add drawString and then you need stringOnPath, clipping, styling of the texts, multiline strings, full support of unicode, ... and then you end up with a programmatic only version of SVG. I meant: Canvas does NOT have... Sorry if this lead to any confusion. Regards, -- Mathieu 'p01' HENRI JavaScript developer, Opera Software ASA
Re: [whatwg] Canvas lack of drawString method
Hi, I would like to second the drawString() request. It makes sense to have a simple API, but it should be balanced with application simplicity and readability to some extent. Doing CSS black magic to overlay text and a Canvas object just seems inadequate for something like axis labeling. As noted earlier by somebody else (did not find the mail...), we would also need a simple Font object, but the minimum requirements seem rather simple: Font Canvas.createFont(String cssFontProperties); Canvas.setFont(Font font) // set current font Canvas.drawString(int x, int y, String text); Font Canvas.getFont() // current font int Font.stringWidth(String s); int Font.getHeight(); // includes leading int Font.getBaselinePosition(); int Font.getAscent(); int Font.getDescent(); Best regards Stefan Haustein Alfonso Baqueiro wrote: Hello Charles, 2006/10/17, Charles Iliya Krempeaux [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hello Alfonso, On 10/17/06, *Alfonso Baqueiro* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? I believe that some people's reason for not wanting to add it was because of Accessibility concerns. Although normal text in a webpage... or even a text image (with the alt attribute filled in properly) could be read by a person with disabilities, text embedded in the canvas element could not. Perhaps people need to think about how to add Accessibility to the canvas while allowing a drawString procedure. Well a drawString method in canvas can be used for drawing the axis labels or values on a dinamic javascript graphic, but is non sense an aural reader read it, theres no way (yet) to read an image to a blinded people, there are cases where is imposible the accessibility, is imposible for a blind to play video games, and accessibility dont stop the video games creation. In the case of images or the canvas the alt attribute could do the job. See ya
Re: [whatwg] Canvas lack of drawString method (p.s.)
p.s.: To simplify coping with changing font sizes, it probably makes sense to add an align parameter (left|center|right top|center|baseline|bottom) to the drawString call... Stefan Haustein wrote: Hi, I would like to second the drawString() request. It makes sense to have a simple API, but it should be balanced with application simplicity and readability to some extent. Doing CSS black magic to overlay text and a Canvas object just seems inadequate for something like axis labeling. As noted earlier by somebody else (did not find the mail...), we would also need a simple Font object, but the minimum requirements seem rather simple: Font Canvas.createFont(String cssFontProperties); Canvas.setFont(Font font) // set current font Canvas.drawString(int x, int y, String text); Font Canvas.getFont() // current font int Font.stringWidth(String s); int Font.getHeight(); // includes leading int Font.getBaselinePosition(); int Font.getAscent(); int Font.getDescent(); Best regards Stefan Haustein Alfonso Baqueiro wrote: Hello Charles, 2006/10/17, Charles Iliya Krempeaux [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hello Alfonso, On 10/17/06, *Alfonso Baqueiro* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? I believe that some people's reason for not wanting to add it was because of Accessibility concerns. Although normal text in a webpage... or even a text image (with the alt attribute filled in properly) could be read by a person with disabilities, text embedded in the canvas element could not. Perhaps people need to think about how to add Accessibility to the canvas while allowing a drawString procedure. Well a drawString method in canvas can be used for drawing the axis labels or values on a dinamic javascript graphic, but is non sense an aural reader read it, theres no way (yet) to read an image to a blinded people, there are cases where is imposible the accessibility, is imposible for a blind to play video games, and accessibility dont stop the video games creation. In the case of images or the canvas the alt attribute could do the job. See ya
Re: [whatwg] Canvas lack of drawString method (p.s.)
Stefan Haustein wrote: p.s.: To simplify coping with changing font sizes, it probably makes sense to add an align parameter (left|center|right top|center|baseline|bottom) to the drawString call... How does that solve the font substitution problem? This is a real problem that people actually have with exactly the use cases you propose (e.g. [1]). [1] http://golem.ph.utexas.edu/~distler/blog/archives/000888.html -- The universe doesn't care what you believe. The wonderful thing about science is that it doesn't ask for your faith, it just asks for your eyes --- http://xkcd.com/c154.html
Re: [whatwg] Canvas lack of drawString method
Hello Stefan,You'll probably need alot of info, about the font, to be able to really handle fonts properly.It's been a while since I've really written that kind of code.But just consider the concept of kerning. Any API would need to expose that kind of info too. See yaOn 10/17/06, Stefan Haustein [EMAIL PROTECTED] wrote: Hi,I would like to second the drawString() request.It makes sense to have a simple API, but it should be balanced withapplication simplicity and readability to some extent. Doing CSS blackmagic to overlay text and a Canvas object just seems inadequate for something like axis labeling.As noted earlier by somebody else (did not find the mail...), we wouldalso need a simple Font object, but the minimum requirements seem rathersimple:Font Canvas.createFont (String cssFontProperties);Canvas.setFont(Font font) // set current fontCanvas.drawString(int x, int y, String text);Font Canvas.getFont() // current fontint Font.stringWidth(String s);int Font.getHeight ();// includes leadingint Font.getBaselinePosition();int Font.getAscent();int Font.getDescent();Best regardsStefan HausteinAlfonso Baqueiro wrote: Hello Charles, 2006/10/17, Charles Iliya Krempeaux [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hello Alfonso, On 10/17/06, *Alfonso Baqueiro* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? I believe that some people's reason for not wanting to add it was because of Accessibility concerns. Although normal text in a webpage... or even a text image (with the alt attribute filled in properly) could be read by a person with disabilities, text embedded in the canvas element could not. Perhaps people need to think about how to add Accessibility to the canvas while allowing a drawString procedure. Well a drawString method in canvas can be used for drawing the axis labels or values on a dinamic _javascript_ graphic, but is non sense an aural reader read it, theres no way (yet) to read an image to a blinded people, there are cases where is imposible the accessibility, is imposible for a blind to play video games, and accessibility dont stop the video games creation. In the case of images or the canvas the alt attribute could do the job. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.casupercanadian @ gmail.comdeveloper weblog: http://ChangeLog.ca/___ Make Televisionhttp://maketelevision.com/ ___ Cars, Motorcycles, Trucks, and Racing... http://tirebiterz.com/
Re: [whatwg] Canvas lack of drawString method (p.s.)
James, the second image exposes exactly the problem that an alignment parameter would solve: TR and 1/2pi could be drawn aligned baseline right to the references point on the y-axis. 0.97 and pi could be drawn aligned top center to the reference points on the x-axis. The badly rendered example image looks like single characters are placed at fixed positions out of context. Of course, this will lead to problems not only when the fonts are substituted, but also for the slight differences in font sizes... Best regards, Stefan James Graham wrote: Stefan Haustein wrote: p.s.: To simplify coping with changing font sizes, it probably makes sense to add an align parameter (left|center|right top|center|baseline|bottom) to the drawString call... How does that solve the font substitution problem? This is a real problem that people actually have with exactly the use cases you propose (e.g. [1]). [1] http://golem.ph.utexas.edu/~distler/blog/archives/000888.html
Re: [whatwg] Canvas lack of drawString method
Charles Iliya Krempeaux wrote: Hello Stefan, You'll probably need alot of info, about the font, to be able to really handle fonts properly. It's been a while since I've really written that kind of code. But just consider the concept of kerning. Any API would need to expose that kind of info too. Hi Charles, that's why I have included Font.stringWidth() in the list of Font methods (and not charWidth()) The proposed methods should be sufficient for basic needs, in particular to cope with scaling issues and to implement a word wrap algorithm. Best regards, Stefan See ya On 10/17/06, *Stefan Haustein* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, I would like to second the drawString() request. It makes sense to have a simple API, but it should be balanced with application simplicity and readability to some extent. Doing CSS black magic to overlay text and a Canvas object just seems inadequate for something like axis labeling. As noted earlier by somebody else (did not find the mail...), we would also need a simple Font object, but the minimum requirements seem rather simple: Font Canvas.createFont (String cssFontProperties); Canvas.setFont(Font font) // set current font Canvas.drawString(int x, int y, String text); Font Canvas.getFont() // current font int Font.stringWidth(String s); int Font.getHeight (); // includes leading int Font.getBaselinePosition(); int Font.getAscent(); int Font.getDescent(); Best regards Stefan Haustein Alfonso Baqueiro wrote: Hello Charles, 2006/10/17, Charles Iliya Krempeaux [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hello Alfonso, On 10/17/06, *Alfonso Baqueiro* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The canvas component is very promising, but the lack of drawString method could be a great error for its success, this lack is a huge limitation, how could you resolve this problem? I believe that some people's reason for not wanting to add it was because of Accessibility concerns. Although normal text in a webpage... or even a text image (with the alt attribute filled in properly) could be read by a person with disabilities, text embedded in the canvas element could not. Perhaps people need to think about how to add Accessibility to the canvas while allowing a drawString procedure. Well a drawString method in canvas can be used for drawing the axis labels or values on a dinamic javascript graphic, but is non sense an aural reader read it, theres no way (yet) to read an image to a blinded people, there are cases where is imposible the accessibility, is imposible for a blind to play video games, and accessibility dont stop the video games creation. In the case of images or the canvas the alt attribute could do the job. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca http://reptile.ca supercanadian @ gmail.com http://gmail.com developer weblog: http://ChangeLog.ca/ ___ Make Televisionhttp://maketelevision.com/ ___ Cars, Motorcycles, Trucks, and Racing... http://tirebiterz.com/
