On Sep 24, 2005, at 17:05, Manuel Mall wrote:
Hi 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".
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.
The current property system models the dominant-baseline property only
as an enum and doesn't provide for its computed value being the above
"scaled-baseline-table".
Any suggestions how to best integrate this into the property system.
Doesn't that mean the getValue on the dominant-baseline property should
not return an enum but a value of type "scaled-baseline-table"?
So, IMHO: No, the property value should be retrieved by getEnum(), and
then the returned value should be used to construct something
corresponding to this scaled-baseline-table, but I think it would be
confusing/misleading to have the property return such a compound value
by itself...
As to how to integrate this: no clear idea ATM, but I'll give it some
thought.
Maybe Finn or others have a few ideas to add?
Cheers,
Andreas
