Baseline attribute of fragments should return multiple baselines

[astearns]

(from SteveZ)

The Layout API spec currently defines the interface to a fragment. One of its attributes is a baseline,

readonly attribute double baseline;

The semantics are given as "The Fragment's baseline specifies where the baseline is positioned"

This is intend to mean the position in Pixels relative to the top of the fragment of the Dominant Baseline.

Discussions on font metics in the Houdini meeting recommended that having more than a single baseline would be preferable. The goal is to have the layout engine report the actual position of all the baselines it knows about. Since most horizontal text is positioned relative to either the alphabetic or the text-bottom baselines ( due to limitations in baseline information in many fonts), these two baselines should be reported. Furthermore, ideographic text (both horizontal and vertical) is often aligned on the central baseline, so that position should also be available, either explictly or implicitly (say by reporting the position of the text-top baseline and using Calc to compute the mid point (central baseline)).

In addition to the above named baseline values, there is still a need to report the position of the dominant baseline. This is reported as an offset value rather than a string name because that position need not match any of the reported baselines; for example, it might be the hanging baseline. If the dominant baseline does correspond to a reported named baseline, its value will match the value for that named baseline.

To meet these needs, we propose that the relevant fragment attributes become

readonly attribute double dominantBaseline readonly attribute double alphabeticBaseline readonly attribute double textBottomBaseline

And readonly attribute double centralBaseline OR readonly attribute double textTopBaseline

(It was suggested that we should use a baseline table dictionary whose keys are the baseline names, but WebIDL does not allow dictionaries as attributes due to issues related to knowing when a live object makes changes to the components of the dictionary. Since there are only a relatively small number of baselines, making each an independent attribute seemed to make sense as an alternative to using a dictionary. It does, however, raise the problem of indicating that the value for a given baseline is not known. Perhaps the NaN value could be used to indicate that a value is not known.)

(Also, the above attribute names are long, but were chosen to match the CSS Inline spec; bike-shedding may be appropriate. )

The semantics of these attributes is that they are an offset in pixels from the top of the fragment to the named or dominant baseline position associated with the first in-flow glyph in the fragment. Note that floats and Initial Letters are not "in-flow" as that term is used here.

Steve Zilles Sent from Samsung tablet

[bfgeek]

So the intent for the layout would be for everything to be in logical coordinates, for example everything would conceptually be laid out LTR-TB. (everything just undergoes a axis shift + rotation)

For baselines and CJK does this mean things get interesting? Do we need a direction the baseline is in? I.e.

partial interface Fragment {
  readonly attribute BaselineOffset? dominantBaseline;
  readonly attribute sequence<BaselineOffset>? alphabeticBaseline;
  // etc
};

enum BaselineOffsetDirection { "inline", "block" };

interface BaselineOffset {
  readonly attribute BaselineOffsetDirection direction;
  readonly attribute double offset;
};