DO NOT REPLY [Bug 36238] - text-align=justify doesn't work on custom fonts
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=36238. 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=36238 --- Additional Comments From [EMAIL PROTECTED] 2005-10-10 08:43 --- (In reply to comment #4) Jeremias, it just tried to reproduce this and couldn't. In my example the custom font aligns just fine. Could it be that it is fixed as a side effect of other changes made by Luca to the Knuth elements for justification? Can you still reproduce it? Yes, I can. I configured the Windows Arial font in the font config and used that font with text-align=justify. -- 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: 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: Problem with table-cell border
Yury Litvinov wrote: Hi, would you please have a look at that FO example. == fo:table fo:table-column column-width=100pt/ fo:table-column column-width=100pt/ fo:table-body fo:table-row !-- there is a bug -- fo:table-cell border-style=solid border-width=1pt padding=7pt fo:block text-align=center one /fo:block /fo:table-cell !-- there is a bug -- fo:table-cell fo:block text-align=center two /fo:block /fo:table-cell /fo:table-row /fo:table-body /fo:table After starting FOP we get: Exception java.lang.ArrayIndexOutOfBoundsException: -1 Assuming you are using latest FOP from SVN Trunk, then the problem is caused by fact that you are using the border-collapse=collapse setting. Even though you haven't specified this on the table element, it is the default value for this setting. If you specify fo:table border-collapse=separate then the example should work. snip/ Chris
Some notes about space-before and space-after in the area tree
Manuel recently introduced the space-before and space-after traits on areas. Right now we're using empty blocks to create spaces between areas, except for lineAreas where Manuel started to use the space-before and space-after traits. Now that space resolution collapses a lot of spaces due to stacking constraints I have to touch a lot of test cases to make them work again, so I thought I'd also change the code that generates the spaces to use the space-before and space-after traits. In this context it is important to note that our Area.getBPDA (=allocated BPD) does not directly relate to the allocation rectangles defines in 4.2.3. It includes space-before and space-after, so cursor advancement still works, now that the empty space areas are not generated anymore (at least in my local code). Jeremias Maerki
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
DO NOT REPLY [Bug 36977] - [PATCH]TextLayoutManager CJK line break
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=36977. 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=36977 --- Additional Comments From [EMAIL PROTECTED] 2005-10-11 07:24 --- Created an attachment (id=16651) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16651action=view) chinese example, includes fo, pdf before and after patch -- 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.
