Re: e-g with padding and borders
Manuel Mall wrote: Next problem: border conditionality - how do I model that with the Knuth approach? At the time I add the Border/Padding start/end boxes we don't have line breaks so they really only cover the .conditionality=discard case. How do I tell the algorithm to leave enough space at the end of each line (and the beginning of the next line) for the borders (in the case of .conditionality=retain)? The sequence of elements representing the inline content starts and ends with a box [1]. Adding another box at the beginning and at the end of the sequence implements retain, as a line break is never allowed to separate two adjacent boxes: so, the left border and padding will always be in same line as the first piece of content, and the breaking algorithm will always reserve enough space. In order to implement discard, glue elements must be used instead: these elements are discarded if they are chosen as a line break or they are adjacent to a line break, and in this case borders and padding will not be painted. I think that a single box or glue element could be created, representing both border and padding, unless the conditionalities of these properties can be different: for example, if it were possible to have border-start.conditionality = discard and padding-start.conditionality = retain two distinct elements should necessarily be created. Regards Luca [1] Or, better, everything should work well if the first and last elements are boxes. Should there be spaces at the beginning and at the end of the inline having borders, they should be handled as non-breaking spaces, in order to avoid a break between the start border and the first word, or between the last word and the end border.
Re: e-g with padding and borders
Manuel Mall wrote: These two paragraphs confuse me - sorry. My understanding was: discard = start/end borders/padding only at the start and end of the whole fo:inline retain = as discard plus start/end borders/padding on the start and end of every line the fo:inline spans. Sorry, you are completely right, I did not understand you were referring to the extra borders needed around a line break. What we need is one or more elements whose overall behaviour is this: - they represent a space (or another legal break point) - if they are not used as a break, they behave like a normal space (or like a not-used hyphenation point) - if they are chosen as a break, they must add something both at the end of the line they end, and at the beginning of the next line This is quite similar to the behaviour of the sequence of elements representing a space in a centered text (in the TextLM.getNextKnuthElements() method); so, in this case we could use: 1 glue width = border/padding at the end of the line = A 2 penalty width = 0, value = 0 3 glue width = space.opt - (A + B), stretch = space.max - space.opt shrink = space.opt - space.min 4 box width = 0 5 penalty width = 0, value = infinity 6 glue with = border/padding at the beginning of the line = B so: - element 1 is a legal break point, but it is never chosen as 2 is better - element 2 is a legal break point: if it is chosen, the ending line will reserve a width of A for border and padding, and the next line will reserve a width of B (the glue 3 is discarded) - element 3 is NOT a legal break because of the preceding penalty - element 5 is NOT a legal break because of its value - element 6 is NOT a legal break because of the preceding penalty - is there is no break, the overall width is A + (space.opt - (A + B)) + B = space.opt In order to make all this work, the TextLM should - know that it is working on text with non-conditional borders - combine this sequence with the one it would create in a normal situation Regards Luca
Re: e-g with padding and borders
Luca, thanks great stuff - that gives me a lot to work with. Manuel On Tue, 6 Sep 2005 06:48 pm, Luca Furini wrote: Manuel Mall wrote: These two paragraphs confuse me - sorry. My understanding was: discard = start/end borders/padding only at the start and end of the whole fo:inline retain = as discard plus start/end borders/padding on the start and end of every line the fo:inline spans. Sorry, you are completely right, I did not understand you were referring to the extra borders needed around a line break. What we need is one or more elements whose overall behaviour is this: - they represent a space (or another legal break point) - if they are not used as a break, they behave like a normal space (or like a not-used hyphenation point) - if they are chosen as a break, they must add something both at the end of the line they end, and at the beginning of the next line This is quite similar to the behaviour of the sequence of elements representing a space in a centered text (in the TextLM.getNextKnuthElements() method); so, in this case we could use: 1 glue width = border/padding at the end of the line = A 2 penalty width = 0, value = 0 3 glue width = space.opt - (A + B), stretch = space.max - space.opt shrink = space.opt - space.min 4 box width = 0 5 penalty width = 0, value = infinity 6 glue with = border/padding at the beginning of the line = B so: - element 1 is a legal break point, but it is never chosen as 2 is better - element 2 is a legal break point: if it is chosen, the ending line will reserve a width of A for border and padding, and the next line will reserve a width of B (the glue 3 is discarded) - element 3 is NOT a legal break because of the preceding penalty - element 5 is NOT a legal break because of its value - element 6 is NOT a legal break because of the preceding penalty - is there is no break, the overall width is A + (space.opt - (A + B)) + B = space.opt In order to make all this work, the TextLM should - know that it is working on text with non-conditional borders - combine this sequence with the one it would create in a normal situation Regards Luca
Re: e-g with padding and borders
On Mon, 5 Sep 2005 03:08 pm, Manuel Mall wrote: Jeremias, thanks for your patience in answering my questions. On Mon, 5 Sep 2005 02:51 pm, Jeremias Maerki wrote: On 04.09.2005 16:34:35 Manuel Mall wrote: snip/ Another question for the Knuth experts. It appears the inline LMs don't make provisions in the IPD for borders/padding on inlines. I assume border/padding is logically like a nbsp; (with the width of the border + padding) in front of the first and after the last character of the inline assuming .conditionality=discard, that is we don't want to have let's say a left border alone on the end of a line with the text starting on the next. For .conditionality=retain this width needs to be reserved as well at the beginning and end of each intermediate line. Any suggestions how this can/should be integrated into the linebreaking algorithm? Exactly like spaces, borders and padding in b-p-d for block-level objects: additional auxiliary boxes and penalties. See BlockStackingLayoutManager.addKnuthElementsFor*(). Line breaking is the same as page breaking, only in a different direction. Thanks for the pointer. I'll have a look at that. That seem to have done the trick. I have copied the Border/Padding before/after logic from BlockStackingLayoutManager and made it into a Border/Padding start/end for the Inline LM. There were some side effects in that the Line LM expectd only KnuthInlineBoxes and now we have some KnuthBoxes as well but I think I solved that ok. Next problem: border conditionality - how do I model that with the Knuth approach? At the time I add the Border/Padding start/end boxes we don't have line breaks so they really only cover the .conditionality=discard case. How do I tell the algorithm to leave enough space at the end of each line (and the beginning of the next line) for the borders (in the case of .conditionality=retain)? snip/ Jeremias Maerki Manuel Manuel
Re: e-g with padding and borders
I think you're reaching a point where you should understand exactly how the Knuth model works. I haven't looked at how conditionality is implemented very closely. Without diving deeper into this myself I'm unable to help right now other than to point you to BlockStackingLayoutManager again which contains at least part of the code that deals with space conditionality. If the comments are right in BlockStackingLayoutManager conditionality has not even been implemented for blocks in the b-p-d. If you really want to go down that road I suggest you get Donald Knuth's Digital Typography or another book that contains the essay Breaking Paragraphs into Lines. There may also be a little information about handling conditionality in the mailing list archives. Sorry that I can't help more, but we're getting into complicated terrain here. On 05.09.2005 14:52:23 Manuel Mall wrote: On Mon, 5 Sep 2005 03:08 pm, Manuel Mall wrote: Jeremias, thanks for your patience in answering my questions. On Mon, 5 Sep 2005 02:51 pm, Jeremias Maerki wrote: On 04.09.2005 16:34:35 Manuel Mall wrote: snip/ Another question for the Knuth experts. It appears the inline LMs don't make provisions in the IPD for borders/padding on inlines. I assume border/padding is logically like a nbsp; (with the width of the border + padding) in front of the first and after the last character of the inline assuming .conditionality=discard, that is we don't want to have let's say a left border alone on the end of a line with the text starting on the next. For .conditionality=retain this width needs to be reserved as well at the beginning and end of each intermediate line. Any suggestions how this can/should be integrated into the linebreaking algorithm? Exactly like spaces, borders and padding in b-p-d for block-level objects: additional auxiliary boxes and penalties. See BlockStackingLayoutManager.addKnuthElementsFor*(). Line breaking is the same as page breaking, only in a different direction. Thanks for the pointer. I'll have a look at that. That seem to have done the trick. I have copied the Border/Padding before/after logic from BlockStackingLayoutManager and made it into a Border/Padding start/end for the Inline LM. There were some side effects in that the Line LM expectd only KnuthInlineBoxes and now we have some KnuthBoxes as well but I think I solved that ok. Next problem: border conditionality - how do I model that with the Knuth approach? At the time I add the Border/Padding start/end boxes we don't have line breaks so they really only cover the .conditionality=discard case. How do I tell the algorithm to leave enough space at the end of each line (and the beginning of the next line) for the borders (in the case of .conditionality=retain)? snip/ Jeremias Maerki Manuel Manuel Jeremias Maerki
Re: e-g with padding and borders
Jeremias Maerki wrote: I think you're reaching a point where you should understand exactly how the Knuth model works. I haven't looked at how conditionality is implemented very closely. Without diving deeper into this myself I'm unable to help right now other than to point you to BlockStackingLayoutManager again which contains at least part of the code that deals with space conditionality. If the comments are right in BlockStackingLayoutManager conditionality has not even been implemented for blocks in the b-p-d. We discussed this just the other day, and I thought the outcome was that space conditionality for blocks in bpd is implemented, but precedence isn't yet. snip/ Chris
Re: e-g with padding and borders
On Mon, 5 Sep 2005 09:51 pm, Jeremias Maerki wrote: I think you're reaching a point where you should understand exactly how the Knuth model works. It had to happen eventually :-). I haven't looked at how conditionality is implemented very closely. Without diving deeper into this myself I'm unable to help right now other than to point you to BlockStackingLayoutManager again which contains at least part of the code that deals with space conditionality. If the comments are right in BlockStackingLayoutManager conditionality has not even been implemented for blocks in the b-p-d. If you really want to go down that road I suggest you get Donald Knuth's Digital Typography or another book that contains the essay Breaking Paragraphs into Lines. There may also be a little information about handling conditionality in the mailing list archives. Sorry that I can't help more, but we're getting into complicated terrain here. That's fine - I am just trying to extract as much information as possible the easy way first. Also, even if conditionality is not implemented may be some of the original designers of the implementation would like to share their thoughts on this topic? I'll see if I can get my hand on the book in the university library here (btw - I am in Perth - Western Australia). In the meantime I'll stick with the discard model which happens to be the default anyway. Manuel On 05.09.2005 14:52:23 Manuel Mall wrote: On Mon, 5 Sep 2005 03:08 pm, Manuel Mall wrote: Jeremias, thanks for your patience in answering my questions. On Mon, 5 Sep 2005 02:51 pm, Jeremias Maerki wrote: On 04.09.2005 16:34:35 Manuel Mall wrote: snip/ Another question for the Knuth experts. It appears the inline LMs don't make provisions in the IPD for borders/padding on inlines. I assume border/padding is logically like a nbsp; (with the width of the border + padding) in front of the first and after the last character of the inline assuming .conditionality=discard, that is we don't want to have let's say a left border alone on the end of a line with the text starting on the next. For .conditionality=retain this width needs to be reserved as well at the beginning and end of each intermediate line. Any suggestions how this can/should be integrated into the linebreaking algorithm? Exactly like spaces, borders and padding in b-p-d for block-level objects: additional auxiliary boxes and penalties. See BlockStackingLayoutManager.addKnuthElementsFor*(). Line breaking is the same as page breaking, only in a different direction. Thanks for the pointer. I'll have a look at that. That seem to have done the trick. I have copied the Border/Padding before/after logic from BlockStackingLayoutManager and made it into a Border/Padding start/end for the Inline LM. There were some side effects in that the Line LM expectd only KnuthInlineBoxes and now we have some KnuthBoxes as well but I think I solved that ok. Next problem: border conditionality - how do I model that with the Knuth approach? At the time I add the Border/Padding start/end boxes we don't have line breaks so they really only cover the .conditionality=discard case. How do I tell the algorithm to leave enough space at the end of each line (and the beginning of the next line) for the borders (in the case of .conditionality=retain)? snip/ Jeremias Maerki Manuel Manuel Jeremias Maerki
Re: e-g with padding and borders
On Sep 2, 2005, at 18:42, Vincent Hennebert wrote: Hi Vincent, You're right. Indeed both situations below are handled by the standard, thanks to border conditionality and is-first/is-last traits. Thanks for the pointer! You're welcome, of course. I have to correct myself on the following, though: By default, the first would be applicable. If the user explicitly specifies border-start-width.conditional=discard, the result would have to be the second. Re-reading the Rec, I believe it should be the other way round: if the border-width is specified as a length, the conditionality is set to discard by default. So, the first of the two would need explicit: border-start-width.conditionality=retain border-end-width.conditionality=retain Cheers, Andreas
Re: e-g with padding and borders
Had a look at this problem (fo:inline with border and padding) and have a question regarding the contract between the area tree and the renderers. The inlineParent area has a property called offset (So have other areas). This offset is used for baseline alignment, i.e. it is the offset relative to the dominant baseline. The question is: Is this offset relative to the content rectangle or the border rectangle? In the example some text fo:inline border=... more text /fo:inline if the offset is for the content rectangle it would be 0 if the offset is for the border rectangle it would be - (Border + Padding) width. Currently the LM sets it to 0. Therefore the renderers would need to compensate for that when drawing the borders (which is currently not done). Alternatively the LM could take the border into account when calculating the offset and the renderers don't need to make any adjustments in the BPD direction. Anyone knows what the original design intention was? Another question for the Knuth experts. It appears the inline LMs don't make provisions in the IPD for borders/padding on inlines. I assume border/padding is logically like a nbsp; (with the width of the border + padding) in front of the first and after the last character of the inline assuming .conditionality=discard, that is we don't want to have let's say a left border alone on the end of a line with the text starting on the next. For .conditionality=retain this width needs to be reserved as well at the beginning and end of each intermediate line. Any suggestions how this can/should be integrated into the linebreaking algorithm? Manuel On Fri, 2 Sep 2005 03:29 pm, Manuel Mall wrote: Allright, I will have a go at this and scream for help if I get stuck. Step 1 would be to get the area tree right and step 2 would be to make any required adjustments to the renderers. This means I will learn more about layout and rendering at the same time (need to have a positive angle to this). Manuel On Fri, 2 Sep 2005 02:44 pm, Jeremias Maerki wrote: Interesting results if you add the following to your test case: fo:block background-color=silver margin=0pt Normal text fo:inline border=solid 5pt red padding=5pt background-color=whiteinline with fo:blockBlah blah/fo:blockfo:blockBlah blah/fo:blockborder=solid 5pt red padding=5pt/fo:inline normal finish /fo:block Looks like a little work. The element list generates boxes with height=12000pt for each of the nested blocks (which seems to be correct), but the renderer increases the currentBPPosition by (2 * (5pt + 5pt)) after painting the inlineblockparents. So there is definitely something wrong with the renderers, too. We probably need to teach them the difference between the normal-allocation-rectangle and the large-allocation-rectangle. On 02.09.2005 08:37:06 Jeremias Maerki wrote: The place to start is certainly the InlineLayoutManager. It looks like the width of the inline is reported correctly through the KnuthElements, but there is either a problem in addAreas or in the renderers that the content of the inline is not indented in i-p-d. Check getExtraIPD() which doesn't seem to be referenced. This could indicate something. The other problem is the b-p-d. Since fo:inline uses the normal-allocation-rectangle (I've check this time), the KnuthElements seem fine concerning the size they report. As with i-p-d I can imagine that there is a problem with the renderers about painting inlines. The bpda of the inlineparent area looks correct to me but it's not painted that way. I think this should all be easily fixable. The real problem IMO is probably block-level content in fo:inlines again. How are these borders to be painted? A border around each inlineblockparent (one for each block inside the inline)? I'm not sure judging from the specification. HTH On 02.09.2005 07:21:49 Manuel Mall wrote: Vincent, Jeremias, thanks for the clarification. After looking just a little bit more into it it appears the current fop version is dealing pretty badly with inline borders and padding. There seem to be no testcases for it either. I'll attach 2 files. A simple test case. The pdf output from that as produced by the current trunk version. The output is wrong on a number of points. 1. The border / padding is overlapping with the text 2. The top/bottom border / padding should be outside the allocation rectangle for the fo:inline and therefore extend above and below the enclosing block. 3. There is a strange gap between the fo:inline and the following text. I suspect it has to do with some piece of code using the correct allocation rectangle and others not. Not sure if I am up to fixing this as that may go into the depth of the Knuth boxes etc.. But if someone if prepared
Re: e-g with padding and borders
The place to start is certainly the InlineLayoutManager. It looks like the width of the inline is reported correctly through the KnuthElements, but there is either a problem in addAreas or in the renderers that the content of the inline is not indented in i-p-d. Check getExtraIPD() which doesn't seem to be referenced. This could indicate something. The other problem is the b-p-d. Since fo:inline uses the normal-allocation-rectangle (I've check this time), the KnuthElements seem fine concerning the size they report. As with i-p-d I can imagine that there is a problem with the renderers about painting inlines. The bpda of the inlineparent area looks correct to me but it's not painted that way. I think this should all be easily fixable. The real problem IMO is probably block-level content in fo:inlines again. How are these borders to be painted? A border around each inlineblockparent (one for each block inside the inline)? I'm not sure judging from the specification. HTH On 02.09.2005 07:21:49 Manuel Mall wrote: Vincent, Jeremias, thanks for the clarification. After looking just a little bit more into it it appears the current fop version is dealing pretty badly with inline borders and padding. There seem to be no testcases for it either. I'll attach 2 files. A simple test case. The pdf output from that as produced by the current trunk version. The output is wrong on a number of points. 1. The border / padding is overlapping with the text 2. The top/bottom border / padding should be outside the allocation rectangle for the fo:inline and therefore extend above and below the enclosing block. 3. There is a strange gap between the fo:inline and the following text. I suspect it has to do with some piece of code using the correct allocation rectangle and others not. Not sure if I am up to fixing this as that may go into the depth of the Knuth boxes etc.. But if someone if prepared to give me some pointers on where to start I'll be prepared to give it a go. Manuel On Fri, 2 Sep 2005 01:04 am, Jeremias Maerki wrote: Oh right. Again someone caught me shooting too fast from the hip. Damn. I will probably never manage to get that right. :-( It's good to have people around to pay attention. I wondered about the large-allocation-rectangle while reading through 6.3.2 but obviously forgot to check the docs for e-g and i-f-o. Sorry, Manuel, Vincent is right. On 01.09.2005 18:44:52 Vincent Hennebert wrote: I'm not sure here. The fo:external-graphic uses the large-allocation-rectangle (§ 6.6.5), that comprises padding and border. This makes me say that in Manuel's example the fo:block's bpd should be calculated with the second formula. The fo:block's content forms a line whose line-stacking-strategy is max-height (default). Thus its allocation rectangle should comprise the image's border padding (§ 4.5). And so does the block. I may be wrong, as this part of the spec is still somewhat unclear to me. WDYT? Vincent Jeremias Maerki a écrit : Indeed, the normal allocation rectangle of an inline area is different than the one of a block area. See 4.3.2. Geometric Definitions in the 1.0 spec. Border and padding for an inline area seem to be outside the allocation rectangle in before and after directions. Interesting. On 01.09.2005 17:29:50 Manuel Mall wrote: I have a follow-up question on this. If we have something as simple(?) as this: fo:block background-color=orange fo:external-graphic src=../../resources/images/bgimg300dpi.jpg border=solid 5pt padding=5pt background-color=white/ /fo:block would you expect the whole image including padding and borders to be within the bounds of the enclosing block or only the actual image to be in the block and the padding and borders to stick out at the top and bottom. It seems xep takes the latter approach and I am very uncertain in this area. Or to put it differently is the BPD of the enclosing block bpd = image height + line-spacing or bpd = image-height + top_and_bottom_borders + top_and_bottom_padding + line-spacing ? Manuel snip/ Jeremias Maerki Jeremias Maerki Jeremias Maerki
Re: e-g with padding and borders
Interesting results if you add the following to your test case: fo:block background-color=silver margin=0pt Normal text fo:inline border=solid 5pt red padding=5pt background-color=whiteinline with fo:blockBlah blah/fo:blockfo:blockBlah blah/fo:blockborder=solid 5pt red padding=5pt/fo:inline normal finish /fo:block Looks like a little work. The element list generates boxes with height=12000pt for each of the nested blocks (which seems to be correct), but the renderer increases the currentBPPosition by (2 * (5pt + 5pt)) after painting the inlineblockparents. So there is definitely something wrong with the renderers, too. We probably need to teach them the difference between the normal-allocation-rectangle and the large-allocation-rectangle. On 02.09.2005 08:37:06 Jeremias Maerki wrote: The place to start is certainly the InlineLayoutManager. It looks like the width of the inline is reported correctly through the KnuthElements, but there is either a problem in addAreas or in the renderers that the content of the inline is not indented in i-p-d. Check getExtraIPD() which doesn't seem to be referenced. This could indicate something. The other problem is the b-p-d. Since fo:inline uses the normal-allocation-rectangle (I've check this time), the KnuthElements seem fine concerning the size they report. As with i-p-d I can imagine that there is a problem with the renderers about painting inlines. The bpda of the inlineparent area looks correct to me but it's not painted that way. I think this should all be easily fixable. The real problem IMO is probably block-level content in fo:inlines again. How are these borders to be painted? A border around each inlineblockparent (one for each block inside the inline)? I'm not sure judging from the specification. HTH On 02.09.2005 07:21:49 Manuel Mall wrote: Vincent, Jeremias, thanks for the clarification. After looking just a little bit more into it it appears the current fop version is dealing pretty badly with inline borders and padding. There seem to be no testcases for it either. I'll attach 2 files. A simple test case. The pdf output from that as produced by the current trunk version. The output is wrong on a number of points. 1. The border / padding is overlapping with the text 2. The top/bottom border / padding should be outside the allocation rectangle for the fo:inline and therefore extend above and below the enclosing block. 3. There is a strange gap between the fo:inline and the following text. I suspect it has to do with some piece of code using the correct allocation rectangle and others not. Not sure if I am up to fixing this as that may go into the depth of the Knuth boxes etc.. But if someone if prepared to give me some pointers on where to start I'll be prepared to give it a go. Manuel On Fri, 2 Sep 2005 01:04 am, Jeremias Maerki wrote: Oh right. Again someone caught me shooting too fast from the hip. Damn. I will probably never manage to get that right. :-( It's good to have people around to pay attention. I wondered about the large-allocation-rectangle while reading through 6.3.2 but obviously forgot to check the docs for e-g and i-f-o. Sorry, Manuel, Vincent is right. On 01.09.2005 18:44:52 Vincent Hennebert wrote: I'm not sure here. The fo:external-graphic uses the large-allocation-rectangle (§ 6.6.5), that comprises padding and border. This makes me say that in Manuel's example the fo:block's bpd should be calculated with the second formula. The fo:block's content forms a line whose line-stacking-strategy is max-height (default). Thus its allocation rectangle should comprise the image's border padding (§ 4.5). And so does the block. I may be wrong, as this part of the spec is still somewhat unclear to me. WDYT? Vincent Jeremias Maerki a écrit : Indeed, the normal allocation rectangle of an inline area is different than the one of a block area. See 4.3.2. Geometric Definitions in the 1.0 spec. Border and padding for an inline area seem to be outside the allocation rectangle in before and after directions. Interesting. On 01.09.2005 17:29:50 Manuel Mall wrote: I have a follow-up question on this. If we have something as simple(?) as this: fo:block background-color=orange fo:external-graphic src=../../resources/images/bgimg300dpi.jpg border=solid 5pt padding=5pt background-color=white/ /fo:block would you expect the whole image including padding and borders to be within the bounds of the enclosing block or only the actual image to be in the block and the padding and borders to stick out at the top and bottom. It seems xep takes the latter approach and I am very uncertain in this area. Or to
Re: e-g with padding and borders
Allright, I will have a go at this and scream for help if I get stuck. Step 1 would be to get the area tree right and step 2 would be to make any required adjustments to the renderers. This means I will learn more about layout and rendering at the same time (need to have a positive angle to this). Manuel On Fri, 2 Sep 2005 02:44 pm, Jeremias Maerki wrote: Interesting results if you add the following to your test case: fo:block background-color=silver margin=0pt Normal text fo:inline border=solid 5pt red padding=5pt background-color=whiteinline with fo:blockBlah blah/fo:blockfo:blockBlah blah/fo:blockborder=solid 5pt red padding=5pt/fo:inline normal finish /fo:block Looks like a little work. The element list generates boxes with height=12000pt for each of the nested blocks (which seems to be correct), but the renderer increases the currentBPPosition by (2 * (5pt + 5pt)) after painting the inlineblockparents. So there is definitely something wrong with the renderers, too. We probably need to teach them the difference between the normal-allocation-rectangle and the large-allocation-rectangle. On 02.09.2005 08:37:06 Jeremias Maerki wrote: The place to start is certainly the InlineLayoutManager. It looks like the width of the inline is reported correctly through the KnuthElements, but there is either a problem in addAreas or in the renderers that the content of the inline is not indented in i-p-d. Check getExtraIPD() which doesn't seem to be referenced. This could indicate something. The other problem is the b-p-d. Since fo:inline uses the normal-allocation-rectangle (I've check this time), the KnuthElements seem fine concerning the size they report. As with i-p-d I can imagine that there is a problem with the renderers about painting inlines. The bpda of the inlineparent area looks correct to me but it's not painted that way. I think this should all be easily fixable. The real problem IMO is probably block-level content in fo:inlines again. How are these borders to be painted? A border around each inlineblockparent (one for each block inside the inline)? I'm not sure judging from the specification. HTH On 02.09.2005 07:21:49 Manuel Mall wrote: Vincent, Jeremias, thanks for the clarification. After looking just a little bit more into it it appears the current fop version is dealing pretty badly with inline borders and padding. There seem to be no testcases for it either. I'll attach 2 files. A simple test case. The pdf output from that as produced by the current trunk version. The output is wrong on a number of points. 1. The border / padding is overlapping with the text 2. The top/bottom border / padding should be outside the allocation rectangle for the fo:inline and therefore extend above and below the enclosing block. 3. There is a strange gap between the fo:inline and the following text. I suspect it has to do with some piece of code using the correct allocation rectangle and others not. Not sure if I am up to fixing this as that may go into the depth of the Knuth boxes etc.. But if someone if prepared to give me some pointers on where to start I'll be prepared to give it a go. Manuel On Fri, 2 Sep 2005 01:04 am, Jeremias Maerki wrote: Oh right. Again someone caught me shooting too fast from the hip. Damn. I will probably never manage to get that right. :-( It's good to have people around to pay attention. I wondered about the large-allocation-rectangle while reading through 6.3.2 but obviously forgot to check the docs for e-g and i-f-o. Sorry, Manuel, Vincent is right. On 01.09.2005 18:44:52 Vincent Hennebert wrote: I'm not sure here. The fo:external-graphic uses the large-allocation-rectangle (§ 6.6.5), that comprises padding and border. This makes me say that in Manuel's example the fo:block's bpd should be calculated with the second formula. The fo:block's content forms a line whose line-stacking-strategy is max-height (default). Thus its allocation rectangle should comprise the image's border padding (§ 4.5). And so does the block. I may be wrong, as this part of the spec is still somewhat unclear to me. WDYT? Vincent Jeremias Maerki a écrit : Indeed, the normal allocation rectangle of an inline area is different than the one of a block area. See 4.3.2. Geometric Definitions in the 1.0 spec. Border and padding for an inline area seem to be outside the allocation rectangle in before and after directions. Interesting. On 01.09.2005 17:29:50 Manuel Mall wrote: I have a follow-up question on this. If we have something as simple(?) as this: fo:block background-color=orange fo:external-graphic
Re: e-g with padding and borders
The problems reported here with e-g and padding / borders apply equally to i-f-o. It's not too hard to fix. While doing this I noticed that the code for the i-f-o LM and e-g LM is logically largely identical although some bits have been coded slightly differently. Any concerns if I put a common LM for i-f-o, e-g that into the LM inheritance hierarchy (working name ForeignContent LM, i.e. content not native of XSL-FO)? So we have something like: i-f-o LM implements ForeignContent LM e-g LM implements ForeignContent LM and ForeignContent LM implements LeafNode LM. This would allow all the code related to the viewport generation, content scaling, and rectangle sizing for i-f-o and e-g to be in one place only. The i-f-o and e-g LMs would become very small basically only providing the image or foreignObject area to be placed into the viewport. Manuel On Fri, 2 Sep 2005 01:04 am, Jeremias Maerki wrote: Oh right. Again someone caught me shooting too fast from the hip. Damn. I will probably never manage to get that right. :-( It's good to have people around to pay attention. I wondered about the large-allocation-rectangle while reading through 6.3.2 but obviously forgot to check the docs for e-g and i-f-o. Sorry, Manuel, Vincent is right. On 01.09.2005 18:44:52 Vincent Hennebert wrote: I'm not sure here. The fo:external-graphic uses the large-allocation-rectangle (§ 6.6.5), that comprises padding and border. This makes me say that in Manuel's example the fo:block's bpd should be calculated with the second formula. The fo:block's content forms a line whose line-stacking-strategy is max-height (default). Thus its allocation rectangle should comprise the image's border padding (§ 4.5). And so does the block. I may be wrong, as this part of the spec is still somewhat unclear to me. WDYT? Vincent Jeremias Maerki a écrit : Indeed, the normal allocation rectangle of an inline area is different than the one of a block area. See 4.3.2. Geometric Definitions in the 1.0 spec. Border and padding for an inline area seem to be outside the allocation rectangle in before and after directions. Interesting. On 01.09.2005 17:29:50 Manuel Mall wrote: I have a follow-up question on this. If we have something as simple(?) as this: fo:block background-color=orange fo:external-graphic src=../../resources/images/bgimg300dpi.jpg border=solid 5pt padding=5pt background-color=white/ /fo:block would you expect the whole image including padding and borders to be within the bounds of the enclosing block or only the actual image to be in the block and the padding and borders to stick out at the top and bottom. It seems xep takes the latter approach and I am very uncertain in this area. Or to put it differently is the BPD of the enclosing block bpd = image height + line-spacing or bpd = image-height + top_and_bottom_borders + top_and_bottom_padding + line-spacing ? Manuel snip/ Jeremias Maerki Jeremias Maerki
Re: e-g with padding and borders
On 02.09.2005 15:38:41 Manuel Mall wrote: The problems reported here with e-g and padding / borders apply equally to i-f-o. It's not too hard to fix. While doing this I noticed that the code for the i-f-o LM and e-g LM is logically largely identical although some bits have been coded slightly differently. Any concerns if I put a common LM for i-f-o, e-g that into the LM inheritance hierarchy (working name ForeignContent LM, i.e. content not native of XSL-FO)? So we have something like: i-f-o LM implements ForeignContent LM e-g LM implements ForeignContent LM and ForeignContent LM implements LeafNode LM. You mean extends, not implements, right? This would allow all the code related to the viewport generation, content scaling, and rectangle sizing for i-f-o and e-g to be in one place only. The i-f-o and e-g LMs would become very small basically only providing the image or foreignObject area to be placed into the viewport. +1 to that but since this new class will be abstract I'd like to have it marked as such by naming it AbstractGraphicsLM (which also shows how I would name it). :-) Thanks for handling that. BTW, I'll commit a tiny little change in IFOLM in a few minutes, due to a change in to FO tree. Shouldn't be a problem, though. Well, I hope. :-) Jeremias Maerki
Re: e-g with padding and borders
On Fri, 2 Sep 2005 10:01 pm, Jeremias Maerki wrote: On 02.09.2005 15:38:41 Manuel Mall wrote: The problems reported here with e-g and padding / borders apply equally to i-f-o. It's not too hard to fix. While doing this I noticed that the code for the i-f-o LM and e-g LM is logically largely identical although some bits have been coded slightly differently. Any concerns if I put a common LM for i-f-o, e-g that into the LM inheritance hierarchy (working name ForeignContent LM, i.e. content not native of XSL-FO)? So we have something like: i-f-o LM implements ForeignContent LM e-g LM implements ForeignContent LM and ForeignContent LM implements LeafNode LM. You mean extends, not implements, right? Yes, of course... This would allow all the code related to the viewport generation, content scaling, and rectangle sizing for i-f-o and e-g to be in one place only. The i-f-o and e-g LMs would become very small basically only providing the image or foreignObject area to be placed into the viewport. +1 to that but since this new class will be abstract I'd like to have it marked as such by naming it AbstractGraphicsLM (which also shows how I would name it). :-) Yes, should be Abstract and Graphics is fine with me. Just wasn't sure if all possible i-f-o's will be of a graphic nature. But that doesn't really matter. Thanks for handling that. BTW, I'll commit a tiny little change in IFOLM in a few minutes, due to a change in to FO tree. Shouldn't be a problem, though. Well, I hope. :-) Noted :-) Jeremias Maerki Manuel
Re: e-g with padding and borders
Jeremias Maerki a écrit : The real problem IMO is probably block-level content in fo:inlines again. How are these borders to be painted? A border around each inlineblockparent (one for each block inside the inline)? I'm not sure judging from the specification. Here the spec starts being really complicated. I would say you're right, thought not sure. See the last sentence of § 4.2.2: Unless otherwise specified, the traits of a formatting object are present on each of its generated areas, and with the same value. (However, see sections [4.7.2 Line-building] and [4.9.4 Border, Padding, and Background].). The referred sections don't seem to hold for the fo:inline case. What disturbs me is that when one specifies a border around a chunk of text and there is line-breaking, this border should appear and the end of the first line and the beginning of second line, as below: This is a | chunk of text | - __ | with border | blah blah --- blah blah What is more intuitive and could be expected by a user is the following: __ This is a | chunk of text --- _ with border | blah blah - blah blah but IIUC this is not allowed by the spec. I ask for confirmation here. So the example you provided with the 2 fo:blockblah blah/fo:block is rendered correctly in terms of borders (but there should be no space between them, probably part of the rendering problem you raised). Vincent
Re: e-g with padding and borders
On 02.09.2005 16:22:02 Vincent Hennebert wrote: Jeremias Maerki a écrit : The real problem IMO is probably block-level content in fo:inlines again. How are these borders to be painted? A border around each inlineblockparent (one for each block inside the inline)? I'm not sure judging from the specification. Here the spec starts being really complicated. I would say you're right, thought not sure. See the last sentence of § 4.2.2: Unless otherwise specified, the traits of a formatting object are present on each of its generated areas, and with the same value. (However, see sections [4.7.2 Line-building] and [4.9.4 Border, Padding, and Background].). The referred sections don't seem to hold for the fo:inline case. You mean the two references to 4.7.2 and 4.9.4, right? I agree. What disturbs me is that when one specifies a border around a chunk of text and there is line-breaking, this border should appear and the end of the first line and the beginning of second line, as below: This is a | chunk of text | - __ | with border | blah blah --- blah blah What is more intuitive and could be expected by a user is the following: __ This is a | chunk of text --- _ with border | blah blah - blah blah but IIUC this is not allowed by the spec. I ask for confirmation here. I would agree that this is not allowed by the spec. The traits are the same for all areas. There don't seem to be any exceptions. Actually, I'm glad there aren't that would complicate things even more. :-) But maybe someone who thinks this would be an important feature could probably write an extension for that. :-) So the example you provided with the 2 fo:blockblah blah/fo:block is rendered correctly in terms of borders (but there should be no space between them, probably part of the rendering problem you raised). Exactly. Jeremias Maerki
Re: e-g with padding and borders
What disturbs me is that when one specifies a border around a chunk of text and there is line-breaking, this border should appear and the end of the first line and the beginning of second line, as below: This is a | chunk of text | - __ | with border | blah blah --- blah blah What is more intuitive and could be expected by a user is the following: __ This is a | chunk of text --- _ with border | blah blah - blah blah but IIUC this is not allowed by the spec. I ask for confirmation here. I would agree that this is not allowed by the spec. The traits are the same for all areas. There don't seem to be any exceptions. Actually, I'm glad there aren't that would complicate things even more. :-) But maybe someone who thinks this would be an important feature could probably write an extension for that. :-) I've just checked: with CSS this is the second layout which is rendered. So there would be an incompatibility here between XSL-FO and CSS, which is astonishing as the spec claims several times to promote compatibility. Anyway, it's not an important feature for me :-] Vincent
Re: e-g with padding and borders
Hi Andreas, You're right. Indeed both situations below are handled by the standard, thanks to border conditionality and is-first/is-last traits. Thanks for the pointer! Vincent Andreas L Delmelle a écrit : On Sep 2, 2005, at 17:44, Vincent Hennebert wrote: Hi, snip / This is a | chunk of text | - __ | with border | blah blah --- blah blah What is more intuitive and could be expected by a user is the following: __ This is a | chunk of text --- _ with border | blah blah - blah blah snip / Hmm... I remember reading something about this --wait a minute... Yep! Got it. See Rec 4.3.1 Space resolution rules all the way down The border or padding at the start-edge or end-edge of an inline-area I may be specified as conditional. If so, then it is set to zero if its associated edge is a leading edge in a line-area, and the is-first trait of I is false, or if its associated edge is a trailing edge in a line-area, and the is-last trait of I is false. (see also: 7.7.9 border-before-width .. XSL modifications to the CSS Definition) By default, the first would be applicable. If the user explicitly specifies border-start-width.conditional=discard, the result would have to be the second. No extension needed. Cheers, Andreas
Re: e-g with padding and borders
This is definitely wrong, you're right. I know how that got through the tests: The checks are insufficient. The stuff that is checked is definitely ok. But bpd/ipd are not checked. That's the problem. On 01.09.2005 15:53:46 Manuel Mall wrote: I think the area tree viewport generated by the current version for an e-g with padding and borders is wrong. Here is the fo snippet (from external-graphic_border_padding.xml): fo:external-graphic src=../../resources/images/bgimg300dpi.jpg border=solid 5pt padding=5pt background-color=white / and this is the generated viewport: viewport background=color=#ff bap=1 1 1 1 border-after=(solid,#00,5000) border-before=(solid,#00,5000) border-end=(solid,#00,5000) border-start=(solid,#00,5000) bpd=66080 bpda=86080 ipd=66080 ipda=86080 padding-after=5000 padding-before=5000 padding-end=5000 padding-start=5000 image bap=0 0 0 0 bpd=0 ipd=0 pos=1 1 46080 46080 url=../../resources/images/bgimg300dpi.jpg / /viewport The viewport bpd/ipd includes the padding and border width while it should only be the content width of 46080. Am I correct? I am happy to fix it - just would like confirmation that this is actually incorrect. BTW, the generated PDF looks pretty wrong to me as well. Manuel PS: Not sure how that got through the layout engine tests! Jeremias Maerki
Re: e-g with padding and borders
On Thu, 1 Sep 2005 10:13 pm, Jeremias Maerki wrote: This is definitely wrong, you're right. I know how that got through the tests: The checks are insufficient. The stuff that is checked is definitely ok. But bpd/ipd are not checked. That's the problem. Thanks - I'll fix the problem and the test. On 01.09.2005 15:53:46 Manuel Mall wrote: I think the area tree viewport generated by the current version for an e-g with padding and borders is wrong. Here is the fo snippet (from external-graphic_border_padding.xml): fo:external-graphic src=../../resources/images/bgimg300dpi.jpg border=solid 5pt padding=5pt background-color=white / and this is the generated viewport: viewport background=color=#ff bap=1 1 1 1 border-after=(solid,#00,5000) border-before=(solid,#00,5000) border-end=(solid,#00,5000) border-start=(solid,#00,5000) bpd=66080 bpda=86080 ipd=66080 ipda=86080 padding-after=5000 padding-before=5000 padding-end=5000 padding-start=5000 image bap=0 0 0 0 bpd=0 ipd=0 pos=1 1 46080 46080 url=../../resources/images/bgimg300dpi.jpg / /viewport The viewport bpd/ipd includes the padding and border width while it should only be the content width of 46080. Am I correct? I am happy to fix it - just would like confirmation that this is actually incorrect. BTW, the generated PDF looks pretty wrong to me as well. Manuel PS: Not sure how that got through the layout engine tests! Jeremias Maerki Manuel
Re: e-g with padding and borders
Indeed, the normal allocation rectangle of an inline area is different than the one of a block area. See 4.3.2. Geometric Definitions in the 1.0 spec. Border and padding for an inline area seem to be outside the allocation rectangle in before and after directions. Interesting. On 01.09.2005 17:29:50 Manuel Mall wrote: I have a follow-up question on this. If we have something as simple(?) as this: fo:block background-color=orange fo:external-graphic src=../../resources/images/bgimg300dpi.jpg border=solid 5pt padding=5pt background-color=white/ /fo:block would you expect the whole image including padding and borders to be within the bounds of the enclosing block or only the actual image to be in the block and the padding and borders to stick out at the top and bottom. It seems xep takes the latter approach and I am very uncertain in this area. Or to put it differently is the BPD of the enclosing block bpd = image height + line-spacing or bpd = image-height + top_and_bottom_borders + top_and_bottom_padding + line-spacing ? Manuel snip/ Jeremias Maerki
Re: e-g with padding and borders
I'm not sure here. The fo:external-graphic uses the large-allocation-rectangle (§ 6.6.5), that comprises padding and border. This makes me say that in Manuel's example the fo:block's bpd should be calculated with the second formula. The fo:block's content forms a line whose line-stacking-strategy is max-height (default). Thus its allocation rectangle should comprise the image's border padding (§ 4.5). And so does the block. I may be wrong, as this part of the spec is still somewhat unclear to me. WDYT? Vincent Jeremias Maerki a écrit : Indeed, the normal allocation rectangle of an inline area is different than the one of a block area. See 4.3.2. Geometric Definitions in the 1.0 spec. Border and padding for an inline area seem to be outside the allocation rectangle in before and after directions. Interesting. On 01.09.2005 17:29:50 Manuel Mall wrote: I have a follow-up question on this. If we have something as simple(?) as this: fo:block background-color=orange fo:external-graphic src=../../resources/images/bgimg300dpi.jpg border=solid 5pt padding=5pt background-color=white/ /fo:block would you expect the whole image including padding and borders to be within the bounds of the enclosing block or only the actual image to be in the block and the padding and borders to stick out at the top and bottom. It seems xep takes the latter approach and I am very uncertain in this area. Or to put it differently is the BPD of the enclosing block bpd = image height + line-spacing or bpd = image-height + top_and_bottom_borders + top_and_bottom_padding + line-spacing ? Manuel snip/ Jeremias Maerki
Re: e-g with padding and borders
Oh right. Again someone caught me shooting too fast from the hip. Damn. I will probably never manage to get that right. :-( It's good to have people around to pay attention. I wondered about the large-allocation-rectangle while reading through 6.3.2 but obviously forgot to check the docs for e-g and i-f-o. Sorry, Manuel, Vincent is right. On 01.09.2005 18:44:52 Vincent Hennebert wrote: I'm not sure here. The fo:external-graphic uses the large-allocation-rectangle (§ 6.6.5), that comprises padding and border. This makes me say that in Manuel's example the fo:block's bpd should be calculated with the second formula. The fo:block's content forms a line whose line-stacking-strategy is max-height (default). Thus its allocation rectangle should comprise the image's border padding (§ 4.5). And so does the block. I may be wrong, as this part of the spec is still somewhat unclear to me. WDYT? Vincent Jeremias Maerki a écrit : Indeed, the normal allocation rectangle of an inline area is different than the one of a block area. See 4.3.2. Geometric Definitions in the 1.0 spec. Border and padding for an inline area seem to be outside the allocation rectangle in before and after directions. Interesting. On 01.09.2005 17:29:50 Manuel Mall wrote: I have a follow-up question on this. If we have something as simple(?) as this: fo:block background-color=orange fo:external-graphic src=../../resources/images/bgimg300dpi.jpg border=solid 5pt padding=5pt background-color=white/ /fo:block would you expect the whole image including padding and borders to be within the bounds of the enclosing block or only the actual image to be in the block and the padding and borders to stick out at the top and bottom. It seems xep takes the latter approach and I am very uncertain in this area. Or to put it differently is the BPD of the enclosing block bpd = image height + line-spacing or bpd = image-height + top_and_bottom_borders + top_and_bottom_padding + line-spacing ? Manuel snip/ Jeremias Maerki Jeremias Maerki
Re: e-g with padding and borders
Vincent, Jeremias, thanks for the clarification. After looking just a little bit more into it it appears the current fop version is dealing pretty badly with inline borders and padding. There seem to be no testcases for it either. I'll attach 2 files. A simple test case. The pdf output from that as produced by the current trunk version. The output is wrong on a number of points. 1. The border / padding is overlapping with the text 2. The top/bottom border / padding should be outside the allocation rectangle for the fo:inline and therefore extend above and below the enclosing block. 3. There is a strange gap between the fo:inline and the following text. I suspect it has to do with some piece of code using the correct allocation rectangle and others not. Not sure if I am up to fixing this as that may go into the depth of the Knuth boxes etc.. But if someone if prepared to give me some pointers on where to start I'll be prepared to give it a go. Manuel On Fri, 2 Sep 2005 01:04 am, Jeremias Maerki wrote: Oh right. Again someone caught me shooting too fast from the hip. Damn. I will probably never manage to get that right. :-( It's good to have people around to pay attention. I wondered about the large-allocation-rectangle while reading through 6.3.2 but obviously forgot to check the docs for e-g and i-f-o. Sorry, Manuel, Vincent is right. On 01.09.2005 18:44:52 Vincent Hennebert wrote: I'm not sure here. The fo:external-graphic uses the large-allocation-rectangle (§ 6.6.5), that comprises padding and border. This makes me say that in Manuel's example the fo:block's bpd should be calculated with the second formula. The fo:block's content forms a line whose line-stacking-strategy is max-height (default). Thus its allocation rectangle should comprise the image's border padding (§ 4.5). And so does the block. I may be wrong, as this part of the spec is still somewhat unclear to me. WDYT? Vincent Jeremias Maerki a écrit : Indeed, the normal allocation rectangle of an inline area is different than the one of a block area. See 4.3.2. Geometric Definitions in the 1.0 spec. Border and padding for an inline area seem to be outside the allocation rectangle in before and after directions. Interesting. On 01.09.2005 17:29:50 Manuel Mall wrote: I have a follow-up question on this. If we have something as simple(?) as this: fo:block background-color=orange fo:external-graphic src=../../resources/images/bgimg300dpi.jpg border=solid 5pt padding=5pt background-color=white/ /fo:block would you expect the whole image including padding and borders to be within the bounds of the enclosing block or only the actual image to be in the block and the padding and borders to stick out at the top and bottom. It seems xep takes the latter approach and I am very uncertain in this area. Or to put it differently is the BPD of the enclosing block bpd = image height + line-spacing or bpd = image-height + top_and_bottom_borders + top_and_bottom_padding + line-spacing ? Manuel snip/ Jeremias Maerki Jeremias Maerki ?xml version=1.0 encoding=UTF-8? !-- Copyright 2005 The Apache Software Foundation Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- !-- $Id: block_border_padding.xml 265720 2005-09-01 13:29:28Z jeremias $ -- testcase info p This test checks nested blocks with border and padding properties. /p /info fo 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=normal page-width=5in page-height=5in fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=normal white-space-collapse=true fo:flow flow-name=xsl-region-body font-size=10pt fo:block background-color=yellow margin=0pt Start of file /fo:block fo:block background-color=silver margin=0pt Normal text fo:inline border=solid 5pt red padding=5pt background-color=whiteinline with border=solid 5pt red padding=5pt/fo:inline normal finish /fo:block fo:block background-color=yellow margin=0pt End of file /fo:block /fo:flow /fo:page-sequence /fo:root /fo checks !-- First block, no gap -- eval
