Re: Error in computation of inline progression dimension ?
Jeremias Maerki wrote: [Glen Mazza] So Luca is correct that both fo:simple-page-masters should generate the same overall margins of 50 pt. each, no? No. :-) Ok, now I am convinced you are right. Thanks for all your explanations, I always found this part of the recommendation quite obscure! Regards, Luca
Re: Error in computation of inline progression dimension ?
--- Glen Mazza [EMAIL PROTECTED] wrote: This IMO is the fatal flaw in your logic in your previous email. You determined fo:s-p-m and fo:r-b to be type (1) FO's, and hence used the wrong equations in 5.3.2 to determine calculated values for them. They are type (3) FO's, and hence the first two equations can never be relevant for them. Oops! The second equation set in 5.3.2 *can* be relevant for an FO that does not generate areas. It is not applicable for the fo:region-body in Luca's example, however, because margin- was not explicitly specified on it. Hence, we are left with the third equation set. Glen
Re: Error in computation of inline progression dimension ?
Damn, Glen, thanks for being so insistent. I was indeed wrong. You didn't really give me the prove I needed to be rewired but you got me looking again all over the spec and I found what was wrong: It doesn't really matter if the FOs generate reference areas or not, the key is that 5.3.2 is talking exclusively about block-level FOs. See the comment within paratheses in the first and second paragraphs in 5.3.2, for example: There are two more properties, end-indent and start-indent (block-level formatting objects) which correspond... p-s-m and r-b are no block-level FOs. D'Oh! Even though p-s-m and r-b refer to the 7.10 Common Margin Properties-Block, the properties space-before|after and start|end-indent only apply to block-level FOs. Sections 6.4.12 and 6.4.13 explain that the margin-* properties have to be used to calculate the indents for these the two FOs in question. I used start|end-indent. :-( So the 5.3.2 rules cannot be triggered, not because p-s-m and r-b don't generate reference area, but because they are no block-level FOs!!! In this light you were right to complain about my bringing in the block-container example. Still, RenderX is wrong about the block-container thing. That part still stands. RenderX (and AntennaHouse) deliberately chose to break inheritance rules in these cases. This is documented in [1]. But as you say, this is a different story. [1] http://www.w3.org/2001/08/28-XSL-PR-DOC.html (see comment 20) Wow, now I need a pause. Thank you, Glen! Jeremias Maerki
Re: Error in computation of inline progression dimension ?
--- Jeremias Maerki [EMAIL PROTECTED] wrote: It doesn't really matter if the FOs generate reference areas or not, the Well, the Recommendation declares which of the three types each FO belongs to, in the Areas section in each FO definition. It is a static answer that holds for all FO's of a given type, i.e. it is not something dynamically dependent on how a particular instance of an FO is currently used in processing. So there should not need to be any debate of whether any FO (1) generates areas, (2) returns areas, or is (3) used in generating areas -- we would have a bug in the Rec if it were vague for any particular FO. Glen
