Re: Processing model for line formation and the CSS Line Module

On Sunday 2012-02-05 01:45 -0800, Stephen Zilles wrote:
> The Text Module talks about line-breaking and justification so the
> main role of the Line Module is "alignment": alignment of the
> components of a line within the line and the alignment of lines to
> other lines or to the line grid. Here I am assuming that the line
> grid consists of equally spaced "line alignment tables" where a
> line alignment table is a scaled and positioned copy of a baseline
> table for the font, dominant baseline and size in effect when the
> line grid is established. (Since the font-family property takes a
> list of font names, which font's baseline table is used in
> creating the line alignment table needs to be specified. Likely,
> this is the baseline table of the first available font as used in
> CSS 2.1 to align elements with no content.)
> 
> My understanding of the processing model (for horizontal text) is
> the following:
> 
> 1.      Text processing (i.e., line breaking and justification} is
> done first per the Text Module. This determines the content of a
> line and its horizontal extent.

It's actually not this straightforward as a first step, thanks to
floats.  Because of floats (or other exclusions), an increase in the
height of a line could cause a decrease in its width due to
intersection with additional floats.  This requires rerunning line
breaking which could, in turn, reduce the height of the line again.
(However, when this happens, the reduced width needs to remain in
effect; otherwise there would be an infinite loop.)

I believe this could be implemented as a single-pass algorithm,
however, presuming that vertical alignment and line height
calculation are computed as horizontal placement progresses rather
than after it is complete.  (Mozilla, however, implements this as a
multi-pass algorithm; changing this is a long-term plan I have.)

> 2.      For each line constructed in step 1., the components of
> the line (be they individual glyphs, composite glyphs (e.g.,
> ligatures, graphemes), replaced content objects, or spans) are
> aligned, vertically, with respect to its neighbors. In actuality,
> this is a binary process of aligning some alignment point in the
> current component to a baseline (often the dominant baseline) in
> its parent. (The (paragraph) block element is the ultimate parent
> for this alignment. That is, every line is within some (paragraph)
> block (said block may consist solely of the line itself)).(More
> details on vertical alignment below.)
> 
> 3.      Having aligned all the components, it is possible to
> compute the vertical extent of the line. This includes adding
> half-leading, where appropriate, to each component. This vertical
> extent determines the top and bottom of the line box (and Text
> Processing determined its horizontal extent)

I'm not convinced of the value of separating these steps.  Some
values of 'vertical-align' ('text-top', 'text-bottom') align a
position that depends on the half-leading when they're aligning
something textual.

However, I think it is worth separating the handling of what CSS 2.1
calls "aligned subtrees" of elements with 'top' and 'bottom'
vertical alignment:  the alignment of each connected subtree happens
first, and then the subtrees with 'top' and 'bottom' are aligned at
the end.

> 4.      If alignment to a line grid is not specified, then the top
> of the current line box is aligned to the bottom of the previous
> line box if there is one and, otherwise, at the top of the block
> box in which the line box occurs.

There's one additional constraint I can think of here: there are
cases in which line boxes are pushed down due to the presence of
floats, as described in 9.5 (Floats) of CSS 2.1:
  # If a shortened line box is too small to contain any content,
  # then the line box is shifted downward (and its width recomputed)
  # until either some content fits or there are no more floats
  # present.

> More details on vertical alignment.
> ============================

I hope to send comments on this part at some point in the future,
but it's pretty long, and I figured it's worth sending my comments
on the first part sooner rather than later.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Received on Wednesday, 8 February 2012 14:10:40 UTC