when using the border-style="solid" shorthand i get a Exception java.lang.ClassCastException using the four separate properties (border-before-style, ...) works ok.
Created attachment 17110 [details] examples i sayed that it works with separate properties - thats not true. The point seems to be the border-end-style in a inline-object. Here an example fo with one working and one not working paragraph.
Thanks, Gerhard! You're a very good bug hunter! I've been able to isolate the problem into a test case which I've just added to the repository: http://svn.apache.org/viewcvs?rev=351460&view=rev Looks like a more fine-grained method is needed to identify certain element patterns. addALetterSpace() wants to remove a certain pattern but failed to realize that the preceding box is representing a border element from the inline. Inline element list experts, please do your magic. Otherwise, I'll try to figure out a solution when my brain is fresh.
The problem is (again) that the breaking text into lines and words logic crosses inline boundaries and our nested inline processing is getting really in the way. To get around this the code has to 'jump through hoops'. In this case the Knuth sequences returned by getNextKnuthElement are used to reverse engineer words which extend over an inline boundary. This in turn needs to be done to determine if an additional letter space needs to be added as the individual LMs don't do that at a boundary because they don't know if they start/end at the beginning/end of a word or in the middle of a word. Of course this "ranting" about the problem will not get us a solution. In the very short term may be Luca can have a look at this as he as fixed a similar problem before in a related area. After that we really need to redesign the line breaking stuff. Not the Knuth approach (and the implemented algorithms related to that) but the way we arrive at the Knuth sequences and iterate and process the text elements. This needs to be done to be able to do white-space-treatment, UAX#14 line breaking, start- /end- space resolution and generally to be able to handle some more aspects of Unicode (e.g. glyph merging).
Sorry for not answering before, today I hope I'll be able to find some time to look at this. Thanks to you all, the problem has already been defined with precision. As Manuel rightly said, however, we should rethink this part of the process in order to solve this kind of problem once and for all.
Fixed, actually more a hack/workaround. See: http://svn.apache.org/viewcvs?rev=359364&view=rev and http://svn.apache.org/viewcvs?rev=359368&view=rev Sorry, messed up the commits so the bug fix is spread over two svn commits.
*** Bug 38882 has been marked as a duplicate of this bug. ***
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed