W3C home > Mailing lists > Public > www-style@w3.org > August 2013

Re: [css-text] justification and copyfitting

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 20 Aug 2013 17:32:17 -0700
Message-ID: <52140A91.7040307@inkedblade.net>
To: www-style@w3.org
Switching up the subject line, since this is a very different topic...

Bert Bos wrote:
> Justification with spaces or kashida is an example of copyfitting. We
> need other forms of copyfitting as well: changing the font size,
> changing the font stretch and changing the line height (and later also:
> changing the content).
> Maybe 'font-size' can get an extra keyword to indicate that the size may
> increase for the purposes of copyfitting. And likewise for 'line-
> height'. 'Font-stretch' may be allowed to get more condensed. (If
> 'height' is 'auto' and the text is not paginated, line height doesn't
> increase and font size is only used to justify; otherwise both font size
> and line height can increase to fill as much of the height as possible.)

We decided to drop this kind of copyfitting from Level 3, for various
reasons, including the complexity of doing it *well*. So I think we
should revisit the topic, but not right now, if you don't mind. :)

> The current definition of 'text-justify' defines a binary choice: there
> are expansion opportunities or there are not (depending on the content,
> the value of 'letter-spacing', and the value of 'text-justify' itself).
> The different opportunities on a line need not be stretched by the same
> amount, but together they must always fill the whole width.
> However, you may want to expand up to a certain point: if text becomes
> stretched too much, it is better to give up and left-align it, for fear
> of it becoming unreadable. I.e., rather than
>     d                                 e
>     arbeidsongeschiktheidsverzekeringen
>     in Nederland zitten vol  met  lange
>     woorden.
> you'd want
>     de
>     arbeidsongeschiktheidsverzekeringen
>     in Nederland zitten vol  met  lange
>     woorden.
> Authors may want to set the upper limit. E.g. XSL-FO allows to set
> minimum and maximum sizes on inter-word and inter-letter spaces. Or
> maybe it is a good enough if there *is* an upper limit and you can
> decide to apply it or not. E.g., you might have a limit that no text can
> become wider than twice its normal size.

I think this is reasonable, but maybe we can leave that up to the UA
at this level? We can say that the UA *may* impose an upper limit
on how much text can be expanded, and if the limit is exceeded *may*
choose not to expand the line, and give your example.

For CJK content, it's less likely that a limit would be desired;
for Latin, more likely. So such limits need to be sensitive to
the script used.

> To turn the limit off, 'text-justify' could have a keyword 'unlimited',
> which is like 'distribute' except that there is no limit on how much
> text can expand.

I don't think limits should be included in 'text-justify'. Right now
it's about the method, not about numerical limits.

> (This is one of the reasons I often put 'letter-spacing: 0' in my style
> sheets. But that doesn't stop inter-word spaces from expanding too much:
>     de                                oude
>     arbeidsongeschiktheidsverzekeringen in
>     Nederland   zitten   vol   met   lange
>     woorden.
> Another option is to use Media Queries and turn justification off
> altogether on narrow viewports, but that is a rather coarse method.)

It probably depends on how good the hyphenation is. :)

> You may want to guarantee that the last line of a paragraph is visibly
> shorter than the other lines. We could import the XSL-FO property 'last-
> line-end-indent'. In the case the last line is justified, it gives the
> exact amount by which the last line is shorter, otherwise it gives the
> minimum amount. The value can even be negative...

There's proposals for doing similar things for Text L4. The latest one is

   text-balance: <percentage>;
   initial: 0%;

0% means no minimum last line length, 100% means all lines should be
equally filled. Maybe this property could be extended to handle a
maximum last line length as well. In any case, something to be considered
for a later level. :)

Received on Wednesday, 21 August 2013 00:32:44 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:31 UTC