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 Thanks Manuel