You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Manuel Mall <mm...@arcus.com.au> on 2005/09/24 17:05:46 UTC
dominant-baseline property
This is probably for Finn. 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".
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"?
Thanks
Manuel
Re: dominant-baseline property
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 25, 2005, at 12:16, Andreas L Delmelle wrote:
> On Sep 25, 2005, at 05:19, Manuel Mall wrote:
>
>> Hmm, not sure about this one. The actual rules for computing his
>> compound value are actually a bit involved and require information
>> possibly not readily available to the property system.
>
> Aha, then this could also be precisely the reason why the
> dominant-baseline property cannot return a value of
> scaled-baseline-table, but its enum value should be used further
> downstream where all the necessary information has become available.
Manuel, I've been doing a bit more pondering over this question, and I
feel that this is more or less analogous to percentage-resolution (?).
Is that a correct assessment? I mean, the solution could be to have
getEnum() always return the original enum value, but the other getters
I mentioned could be made to have one or more parameters, that serve
the function of passing information back in from wherever the getters
are used --somewhat like CBPB.hasPadding() which passes a
PercentBaseContext back into the property system, which can then be
used by the property system to provide the caller with the computed
value. While the property system can never resolve that percentage by
itself, it can do so when it is provided with the basis for
calculation.
Just an idea. Hope it can be of any use.
Cheers,
Andreas
Re: dominant-baseline property
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 25, 2005, at 05:19, Manuel Mall wrote:
> On Sun, 25 Sep 2005 01:22 am, Andreas L Delmelle wrote:
>>
>> getValue() or getEnum() would always return the original enum value,
>> but the additional getters would provide access to the
>> scaled-baseline-table that is the result of the enum value...
>>
>>
>> What do you and Finn or others familiar with the fo.properties
>> package think about that? Would this work?
>>
>
> Hmm, not sure about this one. The actual rules for computing his
> compound value are actually a bit involved and require information
> possibly not readily available to the property system.
Aha, then this could also be precisely the reason why the
dominant-baseline property cannot return a value of
scaled-baseline-table, but its enum value should be used further
downstream where all the necessary information has become available.
Cheers,
Andreas
Re: dominant-baseline property
Posted by Manuel Mall <mm...@arcus.com.au>.
On Sun, 25 Sep 2005 01:22 am, Andreas L Delmelle wrote:
> On Sep 24, 2005, at 19:09, Andreas L Delmelle wrote:
> > 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?
>
> On second thought, maybe all you really need is to subclass
> EnumProperty to DominantBaselineProperty, and give it three instance
> variables (or an additional ScaledBaselineTable variable)
> corresponding to what is referred to as the
> dominant-baseline-identifier,
> baseline-table and baseline-table-font-size.
>
> The subclass could add one (or three) additional getXXX() methods,
> which would return the associated value(s).
>
> getValue() or getEnum() would always return the original enum value,
> but the additional getters would provide access to the
> scaled-baseline-table that is the result of the enum value...
>
>
> What do you and Finn or others familiar with the fo.properties
> package think about that? Would this work?
>
Hmm, not sure about this one. The actual rules for computing his
compound value are actually a bit involved and require information
possibly not readily available to the property system.
Yes, let's ask others on this list for input...
>
> Cheers,
>
> Andreas
Manuel
Re: dominant-baseline property
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Sep 24, 2005, at 19:09, Andreas L Delmelle wrote:
>
> 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?
On second thought, maybe all you really need is to subclass
EnumProperty to DominantBaselineProperty, and give it three instance
variables (or an additional ScaledBaselineTable variable) corresponding
to what is referred to as the dominant-baseline-identifier,
baseline-table and baseline-table-font-size.
The subclass could add one (or three) additional getXXX() methods,
which would return the associated value(s).
getValue() or getEnum() would always return the original enum value,
but the additional getters would provide access to the
scaled-baseline-table that is the result of the enum value...
What do you and Finn or others familiar with the fo.properties package
think about that? Would this work?
Cheers,
Andreas
Re: dominant-baseline property
Posted by Manuel Mall <mm...@arcus.com.au>.
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
Re: dominant-baseline property
Posted by Finn Bock <bc...@worldonline.dk>.
[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).
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.
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.
regards,
finn
Re: dominant-baseline property
Posted by Manuel Mall <mm...@arcus.com.au>.
On Sun, 25 Sep 2005 01:09 am, Andreas L Delmelle wrote:
> 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.
>
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".
<snip/>
> Cheers,
>
> Andreas
Manuel
Re: dominant-baseline property
Posted by Andreas L Delmelle <a_...@pandora.be>.
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