On Mon, 26 Sep 2005 04:10 pm, Finn Bock wrote:
> [Manuel]
> >>>I just discovered something unusual in the spec. It describes the
> >>>dominant-baseline property in a number of places as:
> >>>'The "dominant-baseline" property is a compound value with three
> >>>components.'
> >>>It then goes on and lists the 3 components as
> >>>"dominant-baseline-identifier", "baseline-table" and
> >>>"baseline-table font-size" collectively referred to as a
> >>>"scaled-baseline-table". Or to put it differently - the computed
> >>>value of the "dominant-baseline" property is a value of type
> >>>"scaled-baseline-table".
> [Andreas]
> >>Not exactly. Read 7.13.5:
> >>
> >>"The 'dominant-baseline' property is used to determine a
> >>scaled-baseline-table. A scaled-baseline-table is a compound value
> >>with three components..."
> >>
> >>So, it's not the property itself which is a compound value, but
> >>rather the property's enum value is used to determine the compound
> >>value of the scaled-baseline-table.
> [Manuel]
> > It also says in 7.13: The primary baseline alignment property is
> > the "dominant-baseline" property. This property has a compound
> > value with three components.
> >
> > And in 5.5.7: The value of this property is a compound value with
> > three components: a baseline-identifier for the dominant-baseline,
> > a baseline-table and a baseline-table font-size.
> >
> > So there is some evidence in the spec that the authors meant that
> > the computed value of the property is of type
> > "scaled-baseline-table".
> I agree, the spec does indeed indicate that the value isn't a simple
> enum. OTOH I have no idea how it should be handled in the property
> system. It isn't a normal compound property (no
> "dominant-baseline.baseline-identifier" sub property).

Agreed, it seems to be an "abnormal" compound property.

> I'm far from being an expert on alignment, but my gut feeling would
> make the "scaled-baseline-table" datatype a class in layoutmgr,
> accessed from LayoutContext and updated at each LM level with the
> alignment properties.

Yes, I had thought about it along very much the same line. Good to know 
I am not alone.

> If you allow me to turn the question around, what would be the
> benefit of having a scaled-baseline-table datatype in the property
> system? I guess that inheritance of values would be the main reason
> which is easy in the property system and somewhat harder in
> LayoutContext. The calculation is the remainging values seems easier
> to do during layout.

Good question - conceptual cleanliness may be?  So far I have been very 
impressed with the property subsystem (and its designer). Therefore, 
whenever I come across something which clearly relates to properties my 
first thought is: Can this be handled by our property system? And if I 
am unsure of the answer - I'll ask here. In this case you confirmed my 
suspicion - its an "abnormal" compound property with special rules to 
determine its computed value and therefore better left to layout. So, 
if I go down this path in implementing I have at least the support of 
our property guru.

> regards,
> finn



Reply via email to