[whatwg] Text APIs on <canvas>

[Mathieu HENRI]

Ian Hickson wrote:
> On Wed, 7 May 2008, Tim Johansson wrote:
>> On Tue, 06 May 2008 05:10:41 +0200, Ian Hickson <ian at hixie.ch> wrote:
>>
>>> I have introduced the following APIs:
>>>
>>>    context.font
>>>    context.textAlign
>>>    context.textBaseline
>>>    context.fillText()
>>>    context.strokeText()
>> strokeText more or less requires a scalable font, which is not available 
>> in all fonts (and frequently not in mobile phones). I cannot see any 
>> comments on what should happen when the specified font is not capable of 
>> generating a stroke. I guess doing a fill instead is the only sensible 
>> thing to do (as the author has no way of knowing which fonts are 
>> available and/or scalable and it's bad if text disappears).
>>
>> Stroking text is complicated as it is generally less common to have 
>> support for it in the font library. I would prefer to see stroking 
>> removed from the spec as it will not work well with all fonts/devices.
> 
> The idea is that only scalable (vector) fonts should be used, since 
> otherwise things will quickly look ugly. I've made the spec require this.
> 
> Going forward the spec is likely to require effects such as adding text to 
> paths, which will require vector data for all fonts used anyway. I don't 
> want to mislead implementators into thinking bitmap fonts are in any way 
> an option in this day and age.

The problem is that bitmap fonts flourish on handheld and devices and, 
as mentioned by others, in high density alphabets. With the Text APIs 
being a MUST, this can be a bugger.



Apropos context.fillText() and the maxWidth attribute, the spec now says

	" 4. If the maxWidth argument was specified and the hypothetical width 
of the inline box in the hypothetical line box is greater than maxWidth 
CSS pixels, then change font to have a more condensed font (if one is 
available or if a reasonably readable one can be synthesised by applying 
a horizontal scale factor to the font) or a smaller font, and return to 
the previous step. "

Scaling the glyphs uniformly, vertically anchored to the textBaseline, 
would look much more coherent and be more predictable for developers 
than applying a non-uniform scaling or changing the font altogether.

If possible I would loose the part about changing the font or applying 
an horizontal scale factor to the font.



-- 
Mathieu 'p01' HENRI
JavaScript developer, Opera Software ASA