On Fri, 26 Aug 2005 05:14 pm, Jeremias Maerki wrote:
> On 26.08.2005 10:41:31 Manuel Mall wrote:
> > The spec says: The percentage is calculated with respect to the
> > corresponding dimension of the closest area ancestor that was
> > generated by a block-level formatting object. If that dimension is
> > not specified explicitly (i.e., it depends on content's
> > block/inline-progression-dimension), the value is interpreted as
> >  "auto".
> >
> > The second sentence of the above statement is currently not
> > implemented resulting in "messed up" output. What is the best way
> > to fix this? Can we do it on the fo tree when the property is
> > constructed, i.e. walk up the tree and see if a corresponding
> > dimension is set explicitly and if not not force the property to
> > "auto"? There are complications like width and height are
> > corresponding properties to i-p-d/b-p-d and writing mode and
> > reference orientation are also relevant. May be this is too much
> > for the fo tree / property construction phase?
> Yes, I think so. It also duplicates code. See below.
> > Alternatively, it must be done in the layout managers / percentage
> > resolution code. But this appears to be non-trivial as well.
> Yes, but the LMs have to resolve the "auto" values anyway with the
> help of the LayoutContext they get passed by the parent. That's one
> more reason why it's a good idea IMO to let the LM provide the
> percentage resolution context.

They do, that's correct. But in this case they have to figure out that 
although a percentage is set on the property they should treat it like 

> > Currently the getValue() call just returns an int. If we want to
> > use an int value to signal back "cannot resolve" we need to reserve
> > a value for that purpose, may be MIN_INT? But this then has to flow
> > through the expression validation logic. Reminds me a bit of
> > handling of NULL values in SQL - nasty.
> Not necessary IMO. The LM needs to check "width.getEnum() !=
> EN_AUTO", for example, and chose the right value. I think this
> paragraph would only have applied if we'd consider doing the
> resolution in the FO tree, right?
The problem is that getEnum() != EN_AUTO is true because a percentage 
was set but the percentage value should be ignored and treated like 
EN_AUTO if no explicit b-p-d was set on the parent. It is that 
particular decision which is not currently handled.

> > Or getValue() could throw an exception - but there are many 100's
> > of calls to getValue() which all would need to be checked then.
> Uh, oh.
> > Or we could set a flag on the property (e.g. isResolved()) to be
> > tested after calls to getValue().
> I believe checking getEnum() should be enough.

I don't think it is - see above.
> > Or we put more logic into the LMs for this. They would have to test
> > the property if it is of type Relative...Property. If so they have
> > to go up the LM chain and check if the ancestor block has an
> > explicit b-p-d, if yes do normal property resolution, if no behave
> > as if the property was set to "auto".
> Have a look at BlockContainerLM. I really think this needs to be done
> in the LMs since they have to know these values anyway and they
> resolve them, too.
> > Any one with better ideas / comments?
> No better comments other than try to provide the necessary values
> through the percentage resolution context and the LMs. I believe it's
> the best way. HTH (and I hope I understand this stuff enough to give
> good advice/comments).
> Jeremias Maerki

Reply via email to