I'm sorry, I'd better shut up if I can't dive fully into this matter.
I'm just wasting your and my time. Finn seems to have a better grip on
On 26.08.2005 11:21:58 Manuel Mall wrote:
> 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