[whatwg] Canvas lack of drawString method

Stefan Haustein sh at kobjects.org
Wed Oct 18 01:39:10 PDT 2006

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):


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,

Andrew Fedoniouk wrote:
> ----- Original Message ----- From: "Stefan Haustein" <sh at kobjects.org>
> Cc: "WHAT Working Group Mailing List" <whatwg at whatwg.org>
> 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 <supercanadian at gmail.com 
>>> <mailto:supercanadian at gmail.com>>:
>>>     Hello Alfonso,
>>>     On 10/17/06, *Alfonso Baqueiro* < abaqueiro at gmail.com
>>>     <mailto:abaqueiro at gmail.com>> 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

More information about the whatwg mailing list