Re: [whatwg] Remove maxWidth from fillText and, strokeText
Date: Fri, 16 Dec 2011 12:33:58 -0500
From: Francis Boumphrey
Message-ID:
FTR, as an implementer, I find maxWidth very useful for the reasons Ian
mentioned
Frank B0umphrey
--
Frank, what do you mean by implementer?
From a developers perspective, I certainly understand that maxWidth saves a few
lines of code;
function scaleDown(ctx, str, maxWidth, font, size) {
while(ctx.measureText(str).width> maxWidth) { size -= 2; ctx.font = size +
'px ' + font; }
// associated fill/stroke if wanted.
}
But that's all it does. It's not implemented widely, it gives the illusion of
being complete. The resulting font size is not exposed to the author and may be
too small to be legible by the viewer. There's no programmatic way to check for
that. Unless you just implement it yourself, in a few lines of code, which is
rather easy to do.
While we could add a ctx.measureText(str, maxWidth) feature, it seems an
unnecessary complication.
If you're using text with Canvas, you ought to be using some smart methods and
considering the minimum font size, and what should be done with the overflow
(such as doing word wrapping).
There's a long history of being conservative with the scope of the Canvas API.
I still do not believe that maxWidth meets the criteria for a necessary
feature. It's very easy to implement it in JS, with the added benefit of having
size data exposed.
-Charles
Re: [whatwg] Remove maxWidth from fillText and strokeText
On Thu, 12 May 2011, Charles Pritchard wrote:
> >
> > Their intent is to ensure that when you have a specific amount of
> > space in which text has to fit, and you don't know exactly what that
> > space is or you don't know exactly what the text is, you can easily
> > work around minor cases of limited space. For example, I use it on the
> > issues chart:
>
> There's no guarantee of legibility
There's never any guarantee of anything. However, within reason this can
maintain legibility.
> there's no exposure as to the actual size of the font being used.
Indeed typically the text would be squeezed, not made smaler.
> It's not (or was not, in the recent past) implemented in many browsers.
IE9, Chrome, Opera, and Firefox all seem to implement it.
> It serves only minor cases. It's unnecessary.
It serves pretty much every time you want to put text on a label and are
pretty sure it'll fit, but it might go slightly over.
> Yes, you can use TextMetrics. So why have this added bloat?
Convenience. This is a trivial cost for significant convenience.
> Most of your philosophy regarding the Canvas API has been to keep out
> unnecessary and unimplemented items. I don't see how this one is any
> different.
It changes multiple lines of code which most authors wouldn't write into
an additional trivial argument that greatly improves the UI. I think
that's a pretty good deal.
> If it were intended, to be more useful, I'd want to see it in
> measureText as well, so that measureText('string', maxWidth) would
> return a font size attribute.
We'll be improving measureText's metrics in due course.
> Your use case, in your data chart, could quite easily have been written
> up without the added attribute. That's why I'm bringing this up.
It could have been done, but I probably wouldn't have bothered if it
wasn't an extra argument.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Remove maxWidth from fillText and strokeText
On 5/11/11 10:00 PM, Ian Hickson wrote:
On Sun, 13 Feb 2011, Charles Pritchard wrote:
Could we remove the optional maxWidth parameter from fillText and strokeText
of CanvasRenderingContext2D.
I don't see them in use anywhere, they're not widely implemented, and I don't
see them fitting any particular common purpose.
Their intent is to ensure that when you have a specific amount of space in
which text has to fit, and you don't know exactly what that space is or
you don't know exactly what the text is, you can easily work around minor
cases of limited space. For example, I use it on the issues chart:
There's no guarantee of legibility, there's no exposure as to the actual
size of the font
being used. It's not (or was not, in the recent past) implemented in
many browsers.
It serves only minor cases. It's unnecessary.
gets there). When the variance is much bigger, you can't rely on just
squeezing the text, you need something more clever.
Yes, you can do it manually if your needs aren't met by the API.
Yes, you can use TextMetrics. So why have this added bloat?
Most of your philosophy regarding the Canvas API has been to keep out
unnecessary
and unimplemented items. I don't see how this one is any different.
If it were intended, to be more useful, I'd want to see it in
measureText as well,
so that measureText('string', maxWidth) would return a font size attribute.
In doing so, I could check to see if the font size is within appropriate
range
for legibility.
Your use case, in your data chart, could quite easily have been written
up without
the added attribute. That's why I'm bringing this up.
maxWidth doesn't flow with other judgments and reasoning put forward
about the canvas spec,
it's not commonly implemented. It's superfluous; easily programmed. And
it's not exposed in TextMetrics, making it difficult
to test for legibility.
Re: [whatwg] Remove maxWidth from fillText and strokeText
On Sun, 13 Feb 2011, Charles Pritchard wrote:
>
> Could we remove the optional maxWidth parameter from fillText and strokeText
> of CanvasRenderingContext2D.
> I don't see them in use anywhere, they're not widely implemented, and I don't
> see them fitting any particular common purpose.
Their intent is to ensure that when you have a specific amount of space in
which text has to fit, and you don't know exactly what that space is or
you don't know exactly what the text is, you can easily work around minor
cases of limited space. For example, I use it on the issues chart:
http://www.whatwg.org/issues/data.html
The labels on the bottom have to fit in a variable amount of space
depending on how many months are showing, and the labels on the left have
to fit in a fixed amount of space but their length varies on the peak of
the graph in the current view.
> fillText("this very long strong", maxWidth) does not ensure any kind of
> readability of the text.
Sure, it's limited to cases where the amount of space varies only a little
from the original expectation, or for where the strings to be drawn vary
only a little from the original expectation, but that's actually a pretty
common situation. For example, in the example above the strings are only
going to be in the range of 1 to, at most, 5 digits (let's hope it never
gets there). When the variance is much bigger, you can't rely on just
squeezing the text, you need something more clever.
> Authors can use measureText to achieve the same effect, with more
> flexibility and better exposure to the actual size of the font that will
> be used.
Yes, you can do it manually if your needs aren't met by the API.
> They can use clip() if they need to ensure glyphs stay within a bounding
> box (something which maxWidth does not provide, despite its intent.
It's not intended for clipping.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
