Re: Inline border / padding and nested blocks
Manuel Mall wrote: inline_border_padding_block_nested.xml. If you run the test case as is you get a Expect inline sequence as first sequence when last paragraph is not null message. The first message refers to the first block in the testcase: I think this has something to do with the correct mixing of block and inline sequences, as the content of the inner block is placed in the first line, while it should be in the second. The output should be: Before inline starting with a block after block After inline but we get starting wit a block Before inine after block After inline Note that the text before and after the inline (containing the nested block) appear in the same line, and this means their elements ended up in the same sequence, while they should be in two different sequences. I'm going to look at what happens in detail ... If you comment everything out and uncomment the last block you get a ClassCastException on a Knuth element. This happens during LineLM.removeElementsForTrailingSpaces(): as you wrote some time ago, at the moment when the LineLM meets a glue element at the end of a sequence it could wrongly deduce it represents a trailing space, while it represents borders / paddings. I'm going to look at the possible patterns that the elements for border and padding can have, and fix the method. Regards Luca
Re: Inline border / padding and nested blocks
On Mon, 10 Oct 2005 08:38 pm, Luca Furini wrote: Manuel Mall wrote: snip/ If you comment everything out and uncomment the last block you get a ClassCastException on a Knuth element. This happens during LineLM.removeElementsForTrailingSpaces(): as you wrote some time ago, at the moment when the LineLM meets a glue element at the end of a sequence it could wrongly deduce it represents a trailing space, while it represents borders / paddings. I'm going to look at the possible patterns that the elements for border and padding can have, and fix the method. Luca, thanks for looking at this so quickly. Is that actually conceptually the right thing to do, that is removing the trailing spaces before the end of a block as part of the Knuth handling? For leading spaces it is done somewhere completely different (and currently in the same piece of code it is done incorrectly for embedded spaces). I have a picture in mind with all white space handling done as part of the layout (area tree building) but before the actual Knuth sequences are constructed. But that's only a rough idea driven by the description of white space handling in the 1.1WD. Regards Luca Manuel
Re: Inline border / padding and nested blocks
Manuel Mall wrote: Is that actually conceptually the right thing to do, that is removing the trailing spaces before the end of a block as part of the Knuth handling? For leading spaces it is done somewhere completely different (and currently in the same piece of code it is done incorrectly for embedded spaces). I'm not sure it is the best place to do it, although I think that before the breaks are computed trailing spaces should exist no more: otherwise, the content width would take into account the width of these spaces too, and right / center alignment could be incorrect. Moreover, a glue just before the elements appended by the LineLM could be a feasible break, and this would create an empty page after the last one with some content. In other words, that removal is there as it could not be performed any later: but the sooner we get rid of the trailing spaces, the better! :-) I have a picture in mind with all white space handling done as part of the layout (area tree building) but before the actual Knuth sequences are constructed. But that's only a rough idea driven by the description of white space handling in the 1.1WD. Would you like to share it with us? I always find the specs quite obscure as far as white space handling is concerned, so your explanation could really be of great help! Regards Luca
Re: Inline border / padding and nested blocks
On Mon, 10 Oct 2005 09:38 pm, Luca Furini wrote: Manuel Mall wrote: Is that actually conceptually the right thing to do, that is removing the trailing spaces before the end of a block as part of the Knuth handling? For leading spaces it is done somewhere completely different (and currently in the same piece of code it is done incorrectly for embedded spaces). I'm not sure it is the best place to do it, although I think that before the breaks are computed trailing spaces should exist no more: otherwise, the content width would take into account the width of these spaces too, and right / center alignment could be incorrect. Moreover, a glue just before the elements appended by the LineLM could be a feasible break, and this would create an empty page after the last one with some content. In other words, that removal is there as it could not be performed any later: but the sooner we get rid of the trailing spaces, the better! :-) I have a picture in mind with all white space handling done as part of the layout (area tree building) but before the actual Knuth sequences are constructed. But that's only a rough idea driven by the description of white space handling in the 1.1WD. Would you like to share it with us? I always find the specs quite obscure as far as white space handling is concerned, so your explanation could really be of great help! This needs quite a bit more thought. Currently, and this is certainly shifting ground, I am considering the following approach. We need to pass whitespace handling information down the Inline LMs via the layout context. The layout context will have the basic information about the relevant values of the white space handling related properties and state information related to it as well. The state information may be just a counter for the number of consecutive eligible spaces encountered so far and some indication if anything has been generated so far. No Knuth elements for spaces are generated until a non space character is encountered. Then whitespace handling for the pending run of spaces is done. This may involve discarding the whole run if its the first in the block (and the white space properties allow it) or generating different Knuth sequences based on the setting of the white-space related properties. For example if we have suppress-before-linebreak we need a Knuth sequence that throws the space away if we break before it but leaves the space if we break after it. This gets even more interesting(?) if we have a run of spaces (non collapsing) but with suppress before/after/always around a linebreak. Again we would need to design the Knuth sequences to handle this correctly. Trailing spaces are handled by looking if any unhandled spaces are left when the getNextKnuthElements call returns to the top inline level (LineLayoutManager) and are then dealt with. I feel a WIKI page upcoming similar to Jeremias space handling... Regards Luca Manuel
Re: Inline border / padding and nested blocks
Manuel Mall I would appreciate if you could please have a look at test case inline_border_padding_block_nested.xml. If you run the test case as is you get a Expect inline sequence as first sequence when last paragraph is not null message. If you comment everything out and uncomment the last block you get a ClassCastException on a Knuth element. For both issues I am a bit out of my depth and hope you could help. First of all, my compliments for your wonderful work! I'll surely have a look at what happens, although I could have no time to do this until monday. Regards Luca
