RE: percentages on i-p-d/b-p-d/height
Manuel Mall wrote: > Any one with better ideas / comments? FOray solved (I think) this problem by a combination of 1) deferring the resolution of any values that are dependent on area tree values until those values are available, and 2) leaving the logic for such resolution in the FOTree (so it can be reused). FOray doesn't use any kind of binding mechanism in the FOTree, so the exercise becomes a matter of passing a parameter containing the appropriate area tree value to the appropriate FOTree method. The FOray FOTree doesn't know anything about layout or AreaTree, but layout and AreaTree can see and use methods in FOTree. I don't have a testing mechanism in place to prove it, but it seems to work. Because FOray intends to support multiple layout strategies, it was important to get this kind of computation into the "right" place so that it does not need to be duplicated. I don't mean to imply that this is "better". I am only hoping that some idea here helps. Victor Mote
Re: percentages on i-p-d/b-p-d/height
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 this area. 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 > "auto". > > > > > > 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 > Manuel Jeremias Maerki
Re: percentages on i-p-d/b-p-d/height
Finn Bock wrote: It sounds just like a job for the property system since it already deals with the corresponding properties and knows if a property is explicitly set. I don't think that there is an existing way to check if a fo is block-level but that can be added (like generatesReferenceAreas()) or just done by hand: The FO's used to have this property. I think Glen removed it o: if (fo.getNameId() == Constants.FO_BLOCK || ... yuk! Chris
Re: percentages on i-p-d/b-p-d/height
On Fri, 26 Aug 2005 06:00 pm, Finn Bock wrote: > [Manuel Mall] > > > 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? > > It sounds just like a job for the property system since it already > deals with the corresponding properties and knows if a property is > explicitly set. > You feel like having a go at it :-)? > regards, > finn Manuel
Re: percentages on i-p-d/b-p-d/height
[Manuel Mall] 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? It sounds just like a job for the property system since it already deals with the corresponding properties and knows if a property is explicitly set. I don't think that there is an existing way to check if a fo is block-level but that can be added (like generatesReferenceAreas()) or just done by hand: if (fo.getNameId() == Constants.FO_BLOCK || ... Alternatively, it must be done in the layout managers / percentage resolution code. But this appears to be non-trivial as well. 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. Ugh. Or getValue() could throw an exception - but there are many 100's of calls to getValue() which all would need to be checked then. Or we could set a flag on the property (e.g. isResolved()) to be tested after calls to getValue(). 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, The knowledge of explicit set properties isn't stored after the fo tree is constructed. This is for memory reasons. if yes do normal property resolution, if no behave as if the property was set to "auto". Any one with better ideas / comments? regards, finn
Re: percentages on i-p-d/b-p-d/height
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 "auto". > > > 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 Manuel
Re: percentages on i-p-d/b-p-d/height
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. > 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? > 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. > 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
percentages on i-p-d/b-p-d/height
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? Alternatively, it must be done in the layout managers / percentage resolution code. But this appears to be non-trivial as well. 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. Or getValue() could throw an exception - but there are many 100's of calls to getValue() which all would need to be checked then. Or we could set a flag on the property (e.g. isResolved()) to be tested after calls to getValue(). 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". Any one with better ideas / comments? Manuel
