Re: 4.3.2 Overconstrained space-specifiers
Thanks, Luca. It does make sense but I'm having trouble mapping your interpretation to what is written in the spec. I wonder: Do you agree with me that my second example wouldn't be affected by the rules described in 4.3.2? Anyway, I think I'm going to let this rest and instead concentrate on detecting overflow situations. After all, this stuff here seems pretty exotic. On 09.12.2005 14:40:01 Luca Furini wrote: > Jeremias Maerki wrote: > > > You will have seen that I've been working on overconstrained documents. > > 5.3.4 Overconstrained Geometry is more or less implemented, so now I > > need to have a look at 4.3.2 which proves quite difficult to understand. > > At least I can't make much sense of it ATM. > > > > [...] > > > > If anyone has an idea what rule 4 in 4.3.1 or the section 4.3.2 is about > > I'd love to read your thoughts. Otherwise, I will run this through the > > XSL editors list. > > I always thought (probably wrongly) these sections of the spec refer to > the page regions, maybe because of the property display-align, and more as > a way to "formally justify" what is usually done than as prescribing some > particular behaviour. > > To be more clear (I hope :-)): region viewports usually have a well-known > height (unless there is only a single page whose height is unbounded); > their area children don't always fill them completely. The content areas > are placed at the top / center / bottom of the viewport according to the > value of display-align: but, as these extra spaces may be in contrast with > the space properties of the first and last child areas, we need, from a > formal point of view, a rule saying that we are allowed to do this, > otherwise the specs would be inconsistent. > > In other words, I always read these rules as: "spaces added ad the top / > bottom of a page to implement display-align have greater precedence than > space-before or space-after traits of the child areas". According to me, > rule 4 should state something like this: "the maximum value of the > space-specifier is set to the difference between the containing height and > the content height". > > Don't know if this makes any sense ... > > Regards > Luca Jeremias Maerki
Re: 4.3.2 Overconstrained space-specifiers
Jeremias Maerki wrote: You will have seen that I've been working on overconstrained documents. 5.3.4 Overconstrained Geometry is more or less implemented, so now I need to have a look at 4.3.2 which proves quite difficult to understand. At least I can't make much sense of it ATM. [...] If anyone has an idea what rule 4 in 4.3.1 or the section 4.3.2 is about I'd love to read your thoughts. Otherwise, I will run this through the XSL editors list. I always thought (probably wrongly) these sections of the spec refer to the page regions, maybe because of the property display-align, and more as a way to "formally justify" what is usually done than as prescribing some particular behaviour. To be more clear (I hope :-)): region viewports usually have a well-known height (unless there is only a single page whose height is unbounded); their area children don't always fill them completely. The content areas are placed at the top / center / bottom of the viewport according to the value of display-align: but, as these extra spaces may be in contrast with the space properties of the first and last child areas, we need, from a formal point of view, a rule saying that we are allowed to do this, otherwise the specs would be inconsistent. In other words, I always read these rules as: "spaces added ad the top / bottom of a page to implement display-align have greater precedence than space-before or space-after traits of the child areas". According to me, rule 4 should state something like this: "the maximum value of the space-specifier is set to the difference between the containing height and the content height". Don't know if this makes any sense ... Regards Luca
4.3.2 Overconstrained space-specifiers
You will have seen that I've been working on overconstrained documents. 5.3.4 Overconstrained Geometry is more or less implemented, so now I need to have a look at 4.3.2 which proves quite difficult to understand. At least I can't make much sense of it ATM. Here's what I found out so far with a some help from Manuel via IM: First of all, what's strange is that the situation in which overconstrainment relaxing is applied is defined more or less by a single example, and a wrong one at that: "for example an incompletely-filled fo:block with a specified size." The problem: fo:block can't have a specified size and therefore can't by incompletely filled. The block-progression-dimension property doesn't apply to fo:block. I assume fo:block-container was meant. Take this example by Manuel: The contents make up 140pt together while the block-container is only 100pt high. A classic overflow scenario, but probably an overconstrained area tree as described by 4.3.2. Assuming display-align="before", the last normal child of P (= the last normal area of the block-container in this case) has a space-after which is subject to overconstrainment relaxing. Ok, so we run this through rule 4 in space-resolution. That means we set the maximum value of the space-specifier of the fo:block to the block-progression-dimension of the containing block-area which is the reference are of the block-container (= 100pt). Right? If yes, that makes the space-after even bigger than before not helping the situation at all. Or what do you do here? test You don't even have a space-after on the last normal child anymore. Bottom line: I don't get it. If anyone has an idea what rule 4 in 4.3.1 or the section 4.3.2 is about I'd love to read your thoughts. Otherwise, I will run this through the XSL editors list. Thanks, Jeremias Maerki