Table of contents

Appendices

4.6 Inline-areas

An inline-area has its own line-height trait, which may be different from the line-height of its containing block-area. This may affect the placement of its ancestor line-area when the line-stacking-strategy is line-height. An inline-area has an actual-baseline-table for its nominal-font. It has a dominant-baseline-identifier trait which determines how its stacked inline-area descendants are to be aligned.

An inline-area may or may not have child areas, and if so it may or may not be a reference-area. The dimensions of the content-rectangle for an inline-area without children is computed as specified by the generating formatting object, as are those of an inline-area with block-area children.

An inline-area with inline-area children has a content-rectangle which extends from its dominant baseline (see [area-font] ) by its text-depth in the block-progression-direction, and in the opposite direction by its text-altitude; in the inline-progression-direction it extends from the start-edge of the allocation-rectangle of its first child to the end-edge of the allocation-rectangle of its last child. The allocation-rectangle of such an inline-area is the same as its content-rectangle.

The allocation-rectangle of an inline-area without children is either the normal-allocation-rectangle or the large-allocation-rectangle, as specified in the description of the generating formatting object.

NOTE: 

When the line-stacking-strategy is line-height, allocation is done with respect to the expanded-rectangle.

Examples of inline-areas with children might include portions of inline mathematical expressions or areas arising from mixed writing systems (left-to-right within right-to-left, for example).

Stacked Inline-areas[top]

Inline-area children of an area are typically stacked in the inline-progression-direction within their parent area, and this is the default method of positioning inline-areas.

Inline-areas are stacked relative to the dominant baseline, as defined above ( [area-font] ).

For a parent area P whose children are inline-areas, P is defined to be properly stacked if all of the following conditions hold:

1. For each inline-area descendant I of P, the start-edge, end-edge, before-edge and after-edge of the allocation-rectangle of I are parallel to corresponding edges of the content-rectangle of the nearest ancestor reference-area of I.

2. For each pair of normal areas I and I' in the subtree below P, if I and I' have an inline-stacking constraint S, then the distance between the adjacent edges of I and I' is consistent with the constraint imposed by the resolved values of the space-specifiers in S.

3. For any inline-area descendant I of P, the distance in the shift-direction from the dominant baseline of P to the alignment-point of I equals the offset between the dominant baseline of P and the baseline of P corresponding to the alignment-baseline trait of I, plus the sum of the baseline-shifts for I and all of its ancestors which are descendants of P.

   The first summand is computed to compensate for mixed writing systems with different baseline types, and the other summands involve deliberate baseline shifts for things like superscripts and subscripts.

Glyph-areas[top]

The most common inline-area is a glyph-area, which contains the representation for a character (or characters) in a particular font.

A glyph-area has an associated nominal-font, determined by the area's typographic traits, which apply to its character data, and a glyph-orientation determined by its writing-mode and reference-orientation, which determine the orientation of the glyph when it is rendered.

The alignment-point and dominant-baseline-identifier of a glyph-area are assigned according to the writing-system in use (e.g., the glyph baseline in Western languages), and are used to control placement of inline-areas descendants of a line-area. The formatter may generate inline-areas with different inline-progression-directions from their parent to accommodate correct inline-area stacking in the case of mixed writing systems.

A glyph-area has no children. Its block-progression-dimension and actual-baseline-table are the same for all glyphs in a font. Conforming implementations may choose to compute the block-progression-dimension for a glyph area based on the actual glyph size rather than using a common size for all glyphs in a font.