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
Error in computation of inline progression dimension ?
I noticed a strange behaviour concerning margins that could be related to the inheritance of start-indend and end-indent, which was discussed a few weeks ago. It seems that in some situations the margins are subtracted twice from the available inline progression dimension. In the little fo file I'm attaching there are two simple-page-masters: - in one of them, left and right margins are set inside simple-page-master itself - in the other, they are set inside region-body In both cases, the page width is 200 points, with left and right margin set to 50 points; so, the line width should be 100 points. In the method PageSequenceLayoutManager.getViewportRectangle(), the computed ipd is right when the margins are set in region-body, but it is 0 if they are set in simple-page-master, because relDims.ipd is already 100 and start- end-indent are 50. As this method has not been modified recently, the error (if this behaviour is really wrong) must be elsewhere ... Regards, Luca ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:svg=http://www.w3.org/2000/svg; fo:layout-master-set fo:simple-page-master master-name=marginsInMaster page-height=800pt page-width=200pt margin-top=60pt margin-bottom=60pt margin-left=50pt margin-right=50pt fo:region-body/ /fo:simple-page-master fo:simple-page-master master-name=marginsInRegion page-height=800pt page-width=200pt margin-top=60pt margin-bottom=60pt fo:region-body margin-left=50pt margin-right=50pt/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=marginsInMaster hyphenate=true language=it text-align=justify fo:flow flow-name=xsl-region-body fo:block background-color=pink font-size=16pt font-weight=bold space-after=5mmcorto piccolo mini super qualcosa corto qui e qui precipitevolissimevolmente e poi ancora bla bla bla e ancora qualche parola./fo:block /fo:flow /fo:page-sequence fo:page-sequence master-reference=marginsInRegion hyphenate=true language=it text-align=justify fo:flow flow-name=xsl-region-body fo:block background-color=pink font-size=16pt font-weight=bold space-after=5mmcorto piccolo mini super qualcosa corto qui e qui precipitevolissimevolmente e poi ancora bla bla bla e ancora qualche parola./fo:block /fo:flow /fo:page-sequence /fo:root
Re: Error in computation of inline progression dimension ?
Hi Luca, the reason for the effect you're seeing is the inheritance of start-indent and end-indent. In your exapmle, if you specify a margin-left and margin-right on the simple-page-master, this results (corresponding properties) in a start-indent and end-indent of 50pt each. Now, because start|end-indent are inherited, region-body also starts with a start-indent and end-indent of 50pt which together with the parent's start-indent accumulates 100pt because each of the FOs are generating a reference area. If you'd do this on nested blocks you wouldn't see this behaviour because they don't establish a new reference area. That's really one of the things I stumbled upon and which I believe after a lot of thinking to be the correct behaviour given by the spec. RenderX seem to have chosen to break inheritance in these cases because they create strange effects like you found out now. It took me some time to get used to it. So in your case you could specify a margin=0pt on the region-body which triggers the first formula given in 5.3.2. If you don't specify margin the inherited value for start-indent is used. There are other instances like on tables where you have to start specifying start-indent=0pt and end-indent=0pt on table-body if you have a margin on fo:table. I'm 99.9% sure that the current behaviour is correct even if it produces strange results for the XSL-FO user. See my layout engine test cases where I have such auxiliary margin and start|end-indent properties in some places. On 15.02.2005 15:03:00 Luca Furini wrote: I noticed a strange behaviour concerning margins that could be related to the inheritance of start-indend and end-indent, which was discussed a few weeks ago. It seems that in some situations the margins are subtracted twice from the available inline progression dimension. In the little fo file I'm attaching there are two simple-page-masters: - in one of them, left and right margins are set inside simple-page-master itself - in the other, they are set inside region-body In both cases, the page width is 200 points, with left and right margin set to 50 points; so, the line width should be 100 points. In the method PageSequenceLayoutManager.getViewportRectangle(), the computed ipd is right when the margins are set in region-body, but it is 0 if they are set in simple-page-master, because relDims.ipd is already 100 and start- end-indent are 50. As this method has not been modified recently, the error (if this behaviour is really wrong) must be elsewhere ... Regards, Luca Jeremias Maerki
Re: Error in computation of inline progression dimension ?
--- Jeremias Maerki [EMAIL PROTECTED] wrote: Hi Luca, the reason for the effect you're seeing is the inheritance of start-indent and end-indent. In your exapmle, if you specify a margin-left and margin-right on the simple-page-master, this results (corresponding properties) in a start-indent and end-indent of 50pt each. Jeremias, I think I am missing something here. Margin-left and margin-right are different properties from start-indent and end-indent, so I'm unsure why inheritance between the two would be applicable in this case. How does specifying margin-left = 50pt result in the start-indent value being set to 50pt? (Corresponding properties just map ***-start to ***-left, etc. for an otherwise-same-named property so CP don't appear to be relevant to this issue. Does the spec declare margin-left and start-indent to be corresponding properties?) Thanks, Glen
Re: Error in computation of inline progression dimension ?
On 15.02.2005 17:46:54 Glen Mazza wrote: --- Jeremias Maerki [EMAIL PROTECTED] wrote: Hi Luca, the reason for the effect you're seeing is the inheritance of start-indent and end-indent. In your exapmle, if you specify a margin-left and margin-right on the simple-page-master, this results (corresponding properties) in a start-indent and end-indent of 50pt each. Jeremias, I think I am missing something here. Margin-left and margin-right are different properties from start-indent and end-indent, so I'm unsure why inheritance between the two would be applicable in this case. How does specifying margin-left = 50pt result in the start-indent value being set to 50pt? First rule in 5.3.2 for FOs that generate reference areas: start-indent = margin-corresponding + padding-corresponding + border-corresponding-width. (Corresponding properties just map ***-start to ***-left, etc. for an otherwise-same-named property so CP don't appear to be relevant to this issue. Does the spec declare margin-left and start-indent to be corresponding properties?) Yes, also in 5.3.2: There are two more properties, end-indent and start-indent (block-level formatting objects) which correspond to the various absolute margin properties. Jeremias Maerki
Re: Error in computation of inline progression dimension ?
Yes, I was probably not 100% correct in my explanation though my interpretation still stands. On 15.02.2005 18:02:14 Glen Mazza wrote: Oh--5.3.2 says: There are two more properties, end-indent and start-indent (block-level formatting objects) which correspond to the various absolute margin properties. I'm uncertain that that means that they are Corresponding Properties however--I wonder if you are reading too much into the word correspond. Jeremias Maerki
Re: Error in computation of inline progression dimension ?
But if start-indent and margin-left are not Corresponding Properties, then the inheritance of 50pt. you gave in your example would not occur. IMO, if start-indent and margin-left were actually intended to be Corresponding Properties, the former would have been named margin-start. Also, margin-before and margin-after (or before-indent and after-indent) corresponding properties would also have been created. The description of Corresponding Properties, 2nd para of 5.1.2, is unfortunately vague about which properties are actually CP's. Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: Yes, I was probably not 100% correct in my explanation though my interpretation still stands. On 15.02.2005 18:02:14 Glen Mazza wrote: Oh--5.3.2 says: There are two more properties, end-indent and start-indent (block-level formatting objects) which correspond to the various absolute margin properties. I'm uncertain that that means that they are Corresponding Properties however--I wonder if you are reading too much into the word correspond. Jeremias Maerki
Re: Error in computation of inline progression dimension ?
In mid January Peter helped me understand what's going on. Please have a look at his explanation [1]. Maybe that makes it clearer. The margin properties are never used directly in the layout engine (I think and hope). I'm always working from *-indent and space-*. I think it's obvious enough from 5.3.2 that *-indent and margin are meant to be corresponding, at least through the rules established therein. Actually, I think 5.1.2 is the section I should have looked at before Peter pointed out my mistake. About corresponding properties it says The simplest example of such properties..., so in my view 5.3.2 describes a complex relationship and so my calling these properties corresponding was really correct. And the rules in 5.3.2 talk about corresponding (margin-corresponding), and to what can they correspond to if not start-indent and end-indent or space-before and space-after depending on the writing mode? If you think the current interpretation is wrong, please present your theory. However, the more I think about this, and the more I'm explaining, the more I can say that I'm sure that the interpretation is correct. [1] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=2078791 On 15.02.2005 18:27:38 Glen Mazza wrote: But if start-indent and margin-left are not Corresponding Properties, then the inheritance of 50pt. you gave in your example would not occur. IMO, if start-indent and margin-left were actually intended to be Corresponding Properties, the former would have been named margin-start. Also, margin-before and margin-after (or before-indent and after-indent) corresponding properties would also have been created. The description of Corresponding Properties, 2nd para of 5.1.2, is unfortunately vague about which properties are actually CP's. Jeremias Maerki
Re: Error in computation of inline progression dimension ?
Jeremias, I am wrong here. This phrase in 5.3.2: If the corresponding absolute margin property is specified on the formatting object... Clearly means that margin *is* a CP, and hence is a CP with start-indent/end-indent as appropriate. Forget that argument--never mind, and I'm sorry that you had to waste time explaining this to me. I may have more questions on your logic though, as I'm studying your original response to Luca. But thankfully we're in agreement on this point. Thanks, Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: In mid January Peter helped me understand what's going on. Please have a look at his explanation [1]. Maybe that makes it clearer. The margin properties are never used directly in the layout engine (I think and hope). I'm always working from *-indent and space-*. I think it's obvious enough from 5.3.2 that *-indent and margin are meant to be corresponding, at least through the rules established therein. Actually, I think 5.1.2 is the section I should have looked at before Peter pointed out my mistake. About corresponding properties it says The simplest example of such properties..., so in my view 5.3.2 describes a complex relationship and so my calling these properties corresponding was really correct. And the rules in 5.3.2 talk about corresponding (margin-corresponding), and to what can they correspond to if not start-indent and end-indent or space-before and space-after depending on the writing mode? If you think the current interpretation is wrong, please present your theory. However, the more I think about this, and the more I'm explaining, the more I can say that I'm sure that the interpretation is correct. [1] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=2078791
Re: Error in computation of inline progression dimension ?
--- Jeremias Maerki [EMAIL PROTECTED] wrote: Hi Luca, the reason for the effect you're seeing is the inheritance of start-indent and end-indent. In your exapmle, if you specify a margin-left and margin-right on the simple-page-master, (margin-left and margin-right of 50pt each on fo:s-p-m) this results (corresponding properties) in a start-indent and end-indent of 50pt each. via the second set of formulas, because margins are explicitly specified and fo:s-p-m does not generate any area and hence does not generate a reference area (although it is used by fo:page-sequence to do so): I agree here. Now, because start|end-indent are inherited, region-body also starts with a start-indent and end-indent of 50pt which I agree, but these properties are not explicitly specified on fo:region-body, so the first two sets of formulae are not relevant here. Nor would they be anyway because I don't believe fo:region-bodies generate reference areas. together with the parent's start-indent accumulates 100pt because each of the FOs are generating a reference area. I don't think so here--I don't believe either fo:s-p-m or fo:region-body generate reference areas--indeed, I don't think anything located outside of fo:page-sequence does. The spec says they are *used* to create a reference area, but they don't generate one themselves. So maybe your calculations here may need changing--because different formulae in 5.3.2 would hence be activated. Section 6.1 [1] says There are three kinds of formatting objects: (1) those that generate areas, (2) those that return areas, but do not generate them, and (3) those that are used in the generation of areas. fo:s-p-m and fo:region-body are type (3), not type (1). fo:s-p-m text: The fo:simple-page-master formatting object generates no area directly. It is used in the generation of pages by an fo:page-sequence. type (3) fo:r-b text: The fo:region-body formatting object is used to generate one region-viewport-area and one region-reference-area whenever an fo:simple-page-master that has an fo:region-body as a child is used to generate a page. (i.e., type 3) [1] http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo-section So in your case you could specify a margin=0pt on the region-body which triggers the first formula given in 5.3.2. Again, I don't think so because fo:region-body never generates a reference-area. Hence, with no explicit specification of margin properites, the third set of formulas then activates: margin-corresponding = start-indent - inherited_value_of(start-indent) - padding-corresponding - border-corresponding-width with the additional rule that: If the start-indent or end-indent properties are not specified their inherited value is used in these formulae. Since start-indent and end-indent were not specified, then we have: margin-corresponding = inherited_value_of(start-indent) - inherited_value_of(start-indent) - padding-corresponding - border-corresponding-width, or zero for the margin properties on fo:region-body. (i.e., we just rely on the 50pt. on simple-page-master.) So Luca is correct that both fo:simple-page-masters should generate the same overall margins of 50 pt. each, no? Thanks, Glen
Re: Error in computation of inline progression dimension ?
On second thought, Jeremias, instead of arguing this, why don't we just compromise at 75pt. margins? ;) Glen --- Glen Mazza [EMAIL PROTECTED] wrote: --- Jeremias Maerki [EMAIL PROTECTED] wrote: Hi Luca, the reason for the effect you're seeing is the inheritance of start-indent and end-indent. In your exapmle, if you specify a margin-left and margin-right on the simple-page-master, (margin-left and margin-right of 50pt each on fo:s-p-m) this results (corresponding properties) in a start-indent and end-indent of 50pt each. via the second set of formulas, because margins are explicitly specified and fo:s-p-m does not generate any area and hence does not generate a reference area (although it is used by fo:page-sequence to do so): I agree here. Now, because start|end-indent are inherited, region-body also starts with a start-indent and end-indent of 50pt which I agree, but these properties are not explicitly specified on fo:region-body, so the first two sets of formulae are not relevant here. Nor would they be anyway because I don't believe fo:region-bodies generate reference areas. together with the parent's start-indent accumulates 100pt because each of the FOs are generating a reference area. I don't think so here--I don't believe either fo:s-p-m or fo:region-body generate reference areas--indeed, I don't think anything located outside of fo:page-sequence does. The spec says they are *used* to create a reference area, but they don't generate one themselves. So maybe your calculations here may need changing--because different formulae in 5.3.2 would hence be activated. Section 6.1 [1] says There are three kinds of formatting objects: (1) those that generate areas, (2) those that return areas, but do not generate them, and (3) those that are used in the generation of areas. fo:s-p-m and fo:region-body are type (3), not type (1). fo:s-p-m text: The fo:simple-page-master formatting object generates no area directly. It is used in the generation of pages by an fo:page-sequence. type (3) fo:r-b text: The fo:region-body formatting object is used to generate one region-viewport-area and one region-reference-area whenever an fo:simple-page-master that has an fo:region-body as a child is used to generate a page. (i.e., type 3) [1] http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo-section So in your case you could specify a margin=0pt on the region-body which triggers the first formula given in 5.3.2. Again, I don't think so because fo:region-body never generates a reference-area. Hence, with no explicit specification of margin properites, the third set of formulas then activates: margin-corresponding = start-indent - inherited_value_of(start-indent) - padding-corresponding - border-corresponding-width with the additional rule that: If the start-indent or end-indent properties are not specified their inherited value is used in these formulae. Since start-indent and end-indent were not specified, then we have: margin-corresponding = inherited_value_of(start-indent) - inherited_value_of(start-indent) - padding-corresponding - border-corresponding-width, or zero for the margin properties on fo:region-body. (i.e., we just rely on the 50pt. on simple-page-master.) So Luca is correct that both fo:simple-page-masters should generate the same overall margins of 50 pt. each, no? Thanks, Glen
Re: Error in computation of inline progression dimension ?
90pt, no less. On 16.02.2005 05:15:36 Glen Mazza wrote: On second thought, Jeremias, instead of arguing this, why don't we just compromise at 75pt. margins? ;) Jeremias Maerki
Re: Error in computation of inline progression dimension ?
I'm afraid that you're wrong here. It's true that s-p-m and region-body don't directly generate reference areas but they also can't, because they are only used as a template for each new page. For for each page they serve as FOs that generate reference areas. But let me give you another example where this is clearer and so you see that your argument doesn't really count in this discussion. Please open test/layoutengine/testcases/block-container3.xml. That test case I wrote specifically to demostrate the effect we're discussing here. You can't deny that block-container generates a reference area directly. So in this test case the block inside the b-c has an effective start-indent of 20pt (10pt + 10pt) much like in Luca's example. If you look at the checks at the end of block-container3.xml you will realize that there is no 2 (millipoints) anywhere. It's simply the effect from the reference area which results in the double indent. So if you wanted to have both text-generating blocks left-aligned at the same position you'd have to specify start-indent=0pt on the block-container or on its nested block to reset the start-indent to 0pt. BTW, I anticipated that I'd have this argument sooner or later. I was rather baffled when I found out how it is supposed to work. So don't worry about wasting my time in this case. I simply hope we can then put it to rest once and for all, ideally documented in a nice Wiki or Web page, so that if that question comes up again, we can simply point people to that page. (additional comments inline) On 16.02.2005 05:02:30 Glen Mazza wrote: snip/ together with the parent's start-indent accumulates 100pt because each of the FOs are generating a reference area. I don't think so here--I don't believe either fo:s-p-m or fo:region-body generate reference areas--indeed, I don't think anything located outside of fo:page-sequence does. The spec says they are *used* to create a reference area, but they don't generate one themselves. So maybe your calculations here may need changing--because different formulae in 5.3.2 would hence be activated. Section 6.1 [1] says There are three kinds of formatting objects: (1) those that generate areas, (2) those that return areas, but do not generate them, and (3) those that are used in the generation of areas. fo:s-p-m and fo:region-body are type (3), not type (1). fo:s-p-m text: The fo:simple-page-master formatting object generates no area directly. It is used in the generation of pages by an fo:page-sequence. type (3) fo:r-b text: The fo:region-body formatting object is used to generate one region-viewport-area and one region-reference-area whenever an fo:simple-page-master that has an fo:region-body as a child is used to generate a page. (i.e., type 3) [1] http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo-section So in your case you could specify a margin=0pt on the region-body which triggers the first formula given in 5.3.2. Again, I don't think so because fo:region-body never generates a reference-area. Hence, with no explicit specification of margin properites, the third set of formulas then activates: margin-corresponding = start-indent - inherited_value_of(start-indent) - padding-corresponding - border-corresponding-width with the additional rule that: If the start-indent or end-indent properties are not specified their inherited value is used in these formulae. Since start-indent and end-indent were not specified, then we have: margin-corresponding = inherited_value_of(start-indent) - inherited_value_of(start-indent) - padding-corresponding - border-corresponding-width, This formula is only used to calculate margin-corresponding. It is not used to calculate the effective indent. Corresponding properties should not be used directly to do the actual calculations that define the layout. Ask yourself: How would you decide when to use what property to calculate the actual indents? That's why the formulas are there to derive start|end-indent from the corresponding properties. The formula you're refferring to here is actually used inside IndentPropertyMaker. It is used to create the margin-corresponding value which is used in the formula sets 1 and 2. or zero for the margin properties on fo:region-body. (i.e., we just rely on the 50pt. on simple-page-master.) So Luca is correct that both fo:simple-page-masters should generate the same overall margins of 50 pt. each, no? No. :-) Jeremias Maerki
