[jira] [Comment Edited] (FOP-2402) footnotes overlap regular content
[ https://issues.apache.org/jira/browse/FOP-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15141518#comment-15141518 ] Andreas L. Delmelle edited comment on FOP-2402 at 2/12/16 7:38 PM: --- More info: As I was playing with the sample, trying to reduce it further to the absolute minimum required to trigger the bug, I noticed that the nested list structure is also a factor, i.e. removing the outer list also resolves the spacing issue. Using either a regular block or a table instead of a list, the issue cannot be reproduced. All the space specifiers can be removed, save for those on the list-items. Guess it will be key to determine exactly what differs in processing between a plain one level list, and a nested list structure, where one list is an item in the other. EDIT - In the meantime, I have traced said difference to the space adjustment ratio that is used when adding the areas. The page-breaks themselves are computed using the optimum space, so nothing wrong there, but it is only when adding the areas that the space is stretched, based on the adjustment ratio assigned to the break possibility. For some reason -- I am not quite there yet -- that ratio, in case of a nested list, is 1.0, which results in the full amount of stretch being applied. This basically comes down to: space-before.maximum is used. When the outer list is removed, the adjustment ratio when adding the areas for that same list item is only 0.05, which results in a much smaller stretch, which makes everything fit nicely. Still TODO: dive deeper in the page-breaking algorithm to find out why exactly this adjustment ratio is much higher in case the list is nested. EDIT 2 - Aha! I think I see the big difference now... In case of the nested list, the page-breaking algorithm is run over a smaller list of combined elements, where the first box is 12pt -- space-before discarded -- and all following boxes are 17pt (= 12pt + 5pt). The list has no glues, i.e. from the point of view of the algorithm there is nothing to stretch/shrink at the given page-break position, and it is all-or-nothing. In case the list is not nested, the page-breaking algorithm gets to see the full set of elements produced by the list, which has the spaces neatly represented by glue elements, which allows the algorithm to play with stretch/shrink at each break position. EDIT 3 - So, the actual root cause of the problem is that a sequence of glue-box produced by a nested LM is merged into a single box. If we can avoid that from happening, it should be solved. The table layout code seems to handle this slightly better, as in: it does not merge glue-box sequences into a single box, but there I noticed that the glues are somehow returned as non-stretchable, which would result in a tiny amount of space between the last list item on the first page and the footnotes. Only in case of a plain block parent is the result as expected (no matter how many levels are nested), because the block LM always returns the sequence it receives from its child LM, with only minimal additions in case the block has borders or spaces set. It does not combine anything. was (Author: adelmelle): More info: As I was playing with the sample, trying to reduce it further to the absolute minimum required to trigger the bug, I noticed that the nested list structure is also a factor, i.e. removing the outer list also resolves the spacing issue. Using either a regular block or a table instead of a list, the issue cannot be reproduced. All the space specifiers can be removed, save for those on the list-items. Guess it will be key to determine exactly what differs in processing between a plain one level list, and a nested list structure, where one list is an item in the other. EDIT - In the meantime, I have traced said difference to the space adjustment ratio that is used when adding the areas. The page-breaks themselves are computed using the optimum space, so nothing wrong there, but it is only when adding the areas that the space is stretched, based on the adjustment ratio assigned to the break possibility. For some reason -- I am not quite there yet -- that ratio, in case of a nested list, is 1.0, which results in the full amount of stretch being applied. This basically comes down to: space-before.maximum is used. When the outer list is removed, the adjustment ratio when adding the areas for that same list item is only 0.05, which results in a much smaller stretch, which makes everything fit nicely. Still TODO: dive deeper in the page-breaking algorithm to find out why exactly this adjustment ratio is much higher in case the list is nested. EDIT 2 - Aha! I think I see the big difference now... In case of the nested list, the page-breaking algorithm is run over a smaller list of combined elements, where the first box is 12pt -- space-bef
[jira] [Comment Edited] (FOP-2402) footnotes overlap regular content
[ https://issues.apache.org/jira/browse/FOP-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15141518#comment-15141518 ] Andreas L. Delmelle edited comment on FOP-2402 at 2/12/16 7:16 PM: --- More info: As I was playing with the sample, trying to reduce it further to the absolute minimum required to trigger the bug, I noticed that the nested list structure is also a factor, i.e. removing the outer list also resolves the spacing issue. Using either a regular block or a table instead of a list, the issue cannot be reproduced. All the space specifiers can be removed, save for those on the list-items. Guess it will be key to determine exactly what differs in processing between a plain one level list, and a nested list structure, where one list is an item in the other. EDIT - In the meantime, I have traced said difference to the space adjustment ratio that is used when adding the areas. The page-breaks themselves are computed using the optimum space, so nothing wrong there, but it is only when adding the areas that the space is stretched, based on the adjustment ratio assigned to the break possibility. For some reason -- I am not quite there yet -- that ratio, in case of a nested list, is 1.0, which results in the full amount of stretch being applied. This basically comes down to: space-before.maximum is used. When the outer list is removed, the adjustment ratio when adding the areas for that same list item is only 0.05, which results in a much smaller stretch, which makes everything fit nicely. Still TODO: dive deeper in the page-breaking algorithm to find out why exactly this adjustment ratio is much higher in case the list is nested. EDIT 2 - Aha! I think I see the big difference now... In case of the nested list, the page-breaking algorithm is run over a smaller list of combined elements, where the first box is 12pt -- space-before discarded -- and all following boxes are 17pt (= 12pt + 5pt). The list has no glues, i.e. from the point of view of the algorithm there is nothing to stretch/shrink at the given page-break position, and it is all-or-nothing. In case the list is not nested, the page-breaking algorithm gets to see the full set of elements produced by the list, which has the spaces neatly represented by glue elements, which allows the algorithm to play with stretch/shrink at each break position. was (Author: adelmelle): More info: As I was playing with the sample, trying to reduce it further to the absolute minimum required to trigger the bug, I noticed that the nested list structure is also a factor, i.e. removing the outer list also resolves the spacing issue. Using either a regular block or a table instead of a list, the issue cannot be reproduced. All the space specifiers can be removed, save for those on the list-items. Guess it will be key to determine exactly what differs in processing between a plain one level list, and a nested list structure, where one list is an item in the other. EDIT - In the meantime, I have traced said difference to the space adjustment ratio that is used when adding the areas. The page-breaks themselves are computed using the optimum space, so nothing wrong there, but it is only when adding the areas that the space is stretched, based on the adjustment ratio assigned to the break possibility. For some reason -- I am not quite there yet -- that ratio, in case of a nested list, is 1.0, which results in the full amount of stretch being applied. This basically comes down to: space-before.maximum is used. When the outer list is removed, the adjustment ratio when adding the areas for that same list item is only 0.05, which results in a much smaller stretch, which makes everything fit nicely. Still TODO: dive deeper in the page-breaking algorithm to find out why exactly this adjustment ratio is much higher in case the list is nested. > footnotes overlap regular content > - > > Key: FOP-2402 > URL: https://issues.apache.org/jira/browse/FOP-2402 > Project: FOP > Issue Type: Bug > Components: layout/block >Affects Versions: trunk > Environment: Ubuntu 14.04, Java 1.7.0_55 >Reporter: Alexey Neyman > Attachments: FOP-2402.fo, FOP-2402.pdf, bad.fo, bad.pdf, > footnotes-fit.pdf > > > We've noticed yet another issue with the rendering of the footnotes where the > footnote is rendered over the regular content. Verified with top-of-trunk > FOP, r1615966. Please refer to the attached FO/PDF files. > > Curiously, if the last fo:list-item is commented out, the preceding > fo:list-items are placed more tightly and as a result, the footnotes do not > overlap with the regular content. This suggests that there's a bug in how the > space between blocks is calculated, but I haven't debugged it furth
[jira] [Comment Edited] (FOP-2402) footnotes overlap regular content
[ https://issues.apache.org/jira/browse/FOP-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15141518#comment-15141518 ] Andreas L. Delmelle edited comment on FOP-2402 at 2/12/16 6:50 PM: --- More info: As I was playing with the sample, trying to reduce it further to the absolute minimum required to trigger the bug, I noticed that the nested list structure is also a factor, i.e. removing the outer list also resolves the spacing issue. Using either a regular block or a table instead of a list, the issue cannot be reproduced. All the space specifiers can be removed, save for those on the list-items. Guess it will be key to determine exactly what differs in processing between a plain one level list, and a nested list structure, where one list is an item in the other. EDIT - In the meantime, I have traced said difference to the space adjustment ratio that is used when adding the areas. The page-breaks themselves are computed using the optimum space, so nothing wrong there, but it is only when adding the areas that the space is stretched, based on the adjustment ratio assigned to the break possibility. For some reason -- I am not quite there yet -- that ratio, in case of a nested list, is 1.0, which results in the full amount of stretch being applied. This basically comes down to: space-before.maximum is used. When the outer list is removed, the adjustment ratio when adding the areas for that same list item is only 0.05, which results in a much smaller stretch, which makes everything fit nicely. Still TODO: dive deeper in the page-breaking algorithm to find out why exactly this adjustment ratio is much higher in case the list is nested. was (Author: adelmelle): More info: As I was playing with the sample, trying to reduce it further to the absolute minimum required to trigger the bug, I noticed that the nested list structure is also a factor, i.e. removing the outer list also resolves the spacing issue. Using either a regular block or a table instead of a list, the issue cannot be reproduced. All the space specifiers can be removed, save for those on the list-items. Guess it will be key to determine exactly what differs in processing between a plain one level list, and a nested list structure, where one list is an item in the other. > footnotes overlap regular content > - > > Key: FOP-2402 > URL: https://issues.apache.org/jira/browse/FOP-2402 > Project: FOP > Issue Type: Bug > Components: layout/block >Affects Versions: trunk > Environment: Ubuntu 14.04, Java 1.7.0_55 >Reporter: Alexey Neyman > Attachments: FOP-2402.fo, FOP-2402.pdf, bad.fo, bad.pdf, > footnotes-fit.pdf > > > We've noticed yet another issue with the rendering of the footnotes where the > footnote is rendered over the regular content. Verified with top-of-trunk > FOP, r1615966. Please refer to the attached FO/PDF files. > > Curiously, if the last fo:list-item is commented out, the preceding > fo:list-items are placed more tightly and as a result, the footnotes do not > overlap with the regular content. This suggests that there's a bug in how the > space between blocks is calculated, but I haven't debugged it further yet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
