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
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 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 :-)? snip/ regards, finn Manuel
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! snip/ Chris
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
