Re: Suggestion: A new text attribute to scale the size of text to follow the size of a box

On Fri, Apr 30, 2010 at 7:17 AM, Bert Bos <bert@w3.org> wrote:
> Another is to minimize the number of lines, i.e., rather make the text a
> bit smaller (up to the minimum font size) than add extra line breaks.

Alternately, forget about scaling text down at all.  Just do linebreak
calculations like normal, then always scale up to make it fit.

We'd actually still have to do some downscaling in the case that an
unwrappable portion is too long, but we could always prefer scaling up
to fit first.

I think this would address the use-case of newspaper headlines in
narrow columns.  You just set a reasonable font-size, and then things
automatically grow slightly when necessary.


> Based on that last option, we considered allowing automatic font sizes
> *only* on the last line of a block of text, where last line is every
> line before a forced line break. Hence the keyword 'size' on
> the 'text-align-last' property. (In the most recent draft, that keyword
> was again dropped, because of these open issues.)

This would be acceptable to me if we can't come up with anything else.

I think, though, that the only real use-cases are:

1) newspaper headlines
2) movie posters
3) last lines of paragraphs
4) single lines of text

1) is solved by preferring upscaling, and only doing downscaling when
strictly necessary.

2) will generally use explicit line-breaks to get the text to wrap
just right, and so will also be solved by preferring upscaling and/or
using text-align-last.

3) doesn't matter quite as much, since we're only talking about the
last line, *after* linebreak computation has already occurred.  There
we can be more flexible in the text-align-last property if necessary.

4) is identical to 3, especially if the author forces it to be
single-line with white-space:nowrap.


> Maybe the people here can collect some evidence of how line breaks are
> chosen: If you justify text by changing the font size, is that always
> after choosing line breaks by hand, or are there cases where the line
> breaks may be chosen by the computer?

I believe in my 4 use-cases above, #1 is automatic (or can be), #2 is
generally hand-chosen, and #3 and #4 are irrelevant, since they don't
line-break at all.


> If the former, we can adopt the relative simple solution
> of 'text-align-last: size' that just adjusts the size of text on a
> single line: choosing line breaks remains an independent operation,
> unchanged from how it works in CSS2, and justifying last lines is an
> extra step that happens afterwards. (There still is the problem of what
> happens when you reach 'min-font-size': does that cause overflow?)

Yes, it must cause overflow.  The only case where you downscale a
last-line is when it's a single unbreakable segment (either a single
word, or a nowrap segment), and in that case overflowing is the only
possible solution when you can't downscale any further.


> If the latter, we need to decide if we want a precise algorithm or can
> leave it to implementations to compete on how pleasing to the eye they
> can make the text.

I think we can get away with a precise algorithm in the latter case:

1) Compute linebreaks as normal.
2) For each line:
  2a) If the line is a single unbreakable segment and is too long,
shrink the font-size until it fits or reaches the minimum.
  2b) If the line is too short, grow the font-size until it fits or
reaches the maximum.
  2c) If the line is still too short, ??? (ignore it, center it, scale
letter-spacing, word-spacing, etc.?)

Step 2c is interesting, I think.  I'm not sure if it's worthwhile to
address, but if it is, it suggests that fitting text should be capable
of taking multiple strategies, using each one in turn until it is
exhausted.  Something like "text-align: fit( font-size 1em 200%,
word-spacing .5 3, center );" meaning "adjust font-size as necessary
until it hits either the min of 1em or the max of 200%, then if it
still doesn't fit adjust word-spacing with a min of .5 and a max of 3,
then if it still doesn't fit, just center it".  Grammar would be "
fit( <fit-strategy> [, <fit-strategy>]* [,<text-align>] ) ".

Again, not sure it's worthwhile to go that far, but if so, this seems
like the most reasonable and general rule, introducing all the
necessary constraints in a relatively readable fashion.

~TJ

Received on Friday, 30 April 2010 15:53:41 UTC