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

Reply via email to