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: [Xmlgraphics-fop Wiki] Update of ExtensionPoints by JeremiasMaerki
Speaking of extensions, I'd like to resurrect the layout extensions that were part of the code used to start the Knuth branch, but I want to be sure I'm allowed to do it. The set of extensions (a couple of new properties, and some new value for an existing one) is aimed to give the user more control about the page breaking: in particular, via these extensions it is possible to give the application a list of properties that can be adjusted in order to fill all the available bpd of a region (in addition / substitution to the spaces between blocks [1]). I started writing a wiki page about these extensions on the wiki at http://wiki.apache.org/xmlgraphics-fop/LayoutExtensions (I really should take some time to finish it!). My highest-priority, short-term task is still to fix the behaviour of page-number and page-number-citation, as I think these formatting object must work in the next release: I have almost done, just have to finish handling the case of justified ext. After that, obviously if there are no objections against this, I'd like to spend some time on the extensions, that I'm sure could come in handy for fop-users producing book-style (or report-style) documents. For example, here is a link to a message in the xsl-editors mailing list requesting a feature which is completely equivalent to one of the layout extensions: http://lists.w3.org/Archives/Public/xsl-editors/2005JulSep/0007.html (many thanks to Jeremias for pointing it out to me!). Should I be allowed to keep working on this subject, I could answer him that fop will soon be able to cope with his request. Regards Luca [1] ... which makes me think that I should work on space resolution rules too ... my to-do list keeps growing longer and longer! :-(
Re: [Xmlgraphics-fop Wiki] Update of ExtensionPoints by JeremiasMaerki
+1 from me, especially since you'll document it properly and because it has the nice side-effect that we get to see more of your great work! On 02.09.2005 09:35:41 Luca Furini wrote: Speaking of extensions, I'd like to resurrect the layout extensions that were part of the code used to start the Knuth branch, but I want to be sure I'm allowed to do it. The set of extensions (a couple of new properties, and some new value for an existing one) is aimed to give the user more control about the page breaking: in particular, via these extensions it is possible to give the application a list of properties that can be adjusted in order to fill all the available bpd of a region (in addition / substitution to the spaces between blocks [1]). I started writing a wiki page about these extensions on the wiki at http://wiki.apache.org/xmlgraphics-fop/LayoutExtensions (I really should take some time to finish it!). My highest-priority, short-term task is still to fix the behaviour of page-number and page-number-citation, as I think these formatting object must work in the next release: I have almost done, just have to finish handling the case of justified ext. After that, obviously if there are no objections against this, I'd like to spend some time on the extensions, that I'm sure could come in handy for fop-users producing book-style (or report-style) documents. For example, here is a link to a message in the xsl-editors mailing list requesting a feature which is completely equivalent to one of the layout extensions: http://lists.w3.org/Archives/Public/xsl-editors/2005JulSep/0007.html (many thanks to Jeremias for pointing it out to me!). Should I be allowed to keep working on this subject, I could answer him that fop will soon be able to cope with his request. Regards Luca [1] ... which makes me think that I should work on space resolution rules too ... my to-do list keeps growing longer and longer! :-( You should see my TODO list! :-) Jeremias Maerki
Re: FOP Visuals
Jeremias Maerki wrote: For those who don't want to run BatchDiffer themselves, I've uploaded a ZIP full of PNGs, one per layout engine test case combined from output from the PDF, PS and Java2D renderers. Just an idea ... what about an option to have the output from two renderers and the XOR between the two? It could help noticing small differences, in the order of a few points, that could otherwise pass unnoticed. Regards Luca
Re: FOP Visuals
Already implemented. :-) I borrowed the code from Batik. See the create-diffs parameter in the config file (documented in the Javadocs of BatchDiffer) which allows to switch the generation of diff images on and off. http://wiki.apache.org/xmlgraphics-fop/VisualTestingFacility On 02.09.2005 10:01:25 Luca Furini wrote: Jeremias Maerki wrote: For those who don't want to run BatchDiffer themselves, I've uploaded a ZIP full of PNGs, one per layout engine test case combined from output from the PDF, PS and Java2D renderers. Just an idea ... what about an option to have the output from two renderers and the XOR between the two? It could help noticing small differences, in the order of a few points, that could otherwise pass unnoticed. Regards Luca Jeremias Maerki
Re: [Xmlgraphics-fop Wiki] Update of ExtensionPoints by JeremiasMaerki
[Luca] Speaking of extensions, I'd like to resurrect the layout extensions That isn't exactly use of the term extension which I'm using and which I think Jeremias is using in the ExtensionPoints wiki. Your extensions are additional useful features, when I talk about extensions it is the ability to dynamicly load additional behaviour without modifying FOP sources. If your features could be implemeted as dynamicly loaded code, the result would be a lean FOP with incredible power ... that were part of the code used to start the Knuth branch, but I want to be sure I'm allowed to do it. .. and you wouldn't have to ask. :-) OTOH, I'm not entirely sure how to design and implement such a system that dynamicly loads code into the layout system. The set of extensions (a couple of new properties, and some new value for an existing one) New properties are fine, new values to existing properties are bad, I think. It basicly makes the fo file into a FOP file, since no other processer can handle the 'illegal' values. It would be better to define fox:display-align=fill which when specified will override the value of display-align. is aimed to give the user more control about the page breaking: in particular, via these extensions it is possible to give the application a list of properties that can be adjusted in order to fill all the available bpd of a region (in addition / substitution to the spaces between blocks [1]). I wonder why you don't mention that line-height is a min/opt/max space. Surely that will (when implemented) be usefull way to limit the size og empty areas. regards, finn
Re: [Xmlgraphics-fop Wiki] Update of ExtensionPoints by JeremiasMaerki
On 02.09.2005 10:24:12 Finn Bock wrote: [Luca] Speaking of extensions, I'd like to resurrect the layout extensions That isn't exactly use of the term extension which I'm using and which I think Jeremias is using in the ExtensionPoints wiki. Your extensions are additional useful features, when I talk about extensions it is the ability to dynamicly load additional behaviour without modifying FOP sources. Well, extension is such a generic term, like plug-in (otand yet the concept was patentable/ot). Anyway, I don't think that Luca's extensions differ so much from the extensions I documented in the Wiki. If your features could be implemeted as dynamicly loaded code, the result would be a lean FOP with incredible power ... No quite related to this thread, but just to let you know: I'm currently working on the generic extension mechanism that, for example, renderers will be able to use. I realized it would probably not be much more work to implement it generically than to hard-code the PostScript extensions into FOP. that were part of the code used to start the Knuth branch, but I want to be sure I'm allowed to do it. .. and you wouldn't have to ask. :-) OTOH, I'm not entirely sure how to design and implement such a system that dynamicly loads code into the layout system. Neither am I in this case. At the very least it would involve subclassing certain LMs and dynamically registering them for the layout engine. But that would probably be the least of problems, since the new behaviour goes right into the breaking algorithm. The set of extensions (a couple of new properties, and some new value for an existing one) New properties are fine, new values to existing properties are bad, I think. It basicly makes the fo file into a FOP file, since no other processer can handle the 'illegal' values. It would be better to define fox:display-align=fill which when specified will override the value of display-align. Good point. snip/ Jeremias Maerki
Re: [Xmlgraphics-fop Wiki] Update of ExtensionPoints by JeremiasMaerki
Luca, I'm speaking here as a (future) Fop user. Just to let you know that I'm definitely wanting to support you in this area. I think your extensions would make Fop an extremely powerful typesetting system, that would eventually beat TeX in the quality of page makup. It's all the more interesting for me since my use of Fop would be to produce book-style documents. Just a comment about your Wiki page: I'm not sure that modifying margins would produce visually appealing results. May it not disturb the reader when she notices that margins aren't the same after turning a page? Otherwise I agree with all of your other propositions. I wish you good success, Vincent Luca Furini a écrit : Speaking of extensions, I'd like to resurrect the layout extensions that were part of the code used to start the Knuth branch, but I want to be sure I'm allowed to do it. The set of extensions (a couple of new properties, and some new value for an existing one) is aimed to give the user more control about the page breaking: in particular, via these extensions it is possible to give the application a list of properties that can be adjusted in order to fill all the available bpd of a region (in addition / substitution to the spaces between blocks [1]). I started writing a wiki page about these extensions on the wiki at http://wiki.apache.org/xmlgraphics-fop/LayoutExtensions (I really should take some time to finish it!). My highest-priority, short-term task is still to fix the behaviour of page-number and page-number-citation, as I think these formatting object must work in the next release: I have almost done, just have to finish handling the case of justified ext. After that, obviously if there are no objections against this, I'd like to spend some time on the extensions, that I'm sure could come in handy for fop-users producing book-style (or report-style) documents. For example, here is a link to a message in the xsl-editors mailing list requesting a feature which is completely equivalent to one of the layout extensions: http://lists.w3.org/Archives/Public/xsl-editors/2005JulSep/0007.html (many thanks to Jeremias for pointing it out to me!). Should I be allowed to keep working on this subject, I could answer him that fop will soon be able to cope with his request. Regards Luca [1] ... which makes me think that I should work on space resolution rules too ... my to-do list keeps growing longer and longer! :-(
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
DO NOT REPLY [Bug 36475] New: - Background-color attribute handling for fo:block in RTF rendering
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36475. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36475 Summary: Background-color attribute handling for fo:block in RTF rendering Product: Fop Version: all Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36476] New: - Border attributes handling in RTF rendering
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36476. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36476 Summary: Border attributes handling in RTF rendering Product: Fop Version: all Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36476] - Border attributes handling in RTF rendering
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36476. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36476 --- Additional Comments From [EMAIL PROTECTED] 2005-09-02 18:15 --- Created an attachment (id=16288) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16288action=view) [PATCH] Border support introduced Was: Border-related attributes were ignored. Became: Border support introduced. Nesting borders are supported partially: only two levels of nesting. Consecutive paragraphs with identical border formatting are considered part of a single group with the border information applying to the entire group. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36477] New: - Start-indent and end-indent attributes in RTF rendering
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36477. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36477 Summary: Start-indent and end-indent attributes in RTF rendering Product: Fop Version: all Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36477] - Start-indent and end-indent attributes in RTF rendering
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36477. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36477 --- Additional Comments From [EMAIL PROTECTED] 2005-09-02 18:22 --- Created an attachment (id=16289) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16289action=view) [PATCH] Start-indent and end-indent attributes handling fixed Was: start-indent and end-indent attributes of fo:block were ignored (margins were used instead). Became: start-indent and end-indent are handled as in PDF rendering. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36480] New: - Space support in RTF rendering
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36480. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36480 Summary: Space support in RTF rendering Product: Fop Version: all Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: general AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 36480] - Space support in RTF rendering
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36480. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36480 --- Additional Comments From [EMAIL PROTECTED] 2005-09-02 18:32 --- Created an attachment (id=16291) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16291action=view) [PATCH] Space support improved in RTF rendering Was: Space was ignored on empty blocks. Only innermost block spaces was used. Became: Space of emptry blocks a propagated to next block. Space of parent block are propagated to child block. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
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
