Re: [Patch] bug 2243 - extra space at the beginning of next lineafter line feed
Hi Tore, While you're looking at whitespace in LineArea I thought you might be interested in a bug I noticed yesterday. Looking at a table bug report http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2740, I stumbled across a different problem. It turns out that the fo file has lots of trailing whitespace in most of its blocks (fairly common in many formatted .fo files). In fact, it has a structure that looks like this: table-cell -- block |-- whitespace |-- block -- text |-- whitespace The first whitespace gets eliminated in the Block class during the widow handling. Then the nested block gets laid out and fits completely in the remaining space. Then the outer block tries to layout its last child, which is only whitespace. But before discovering that it won't actually create a LineArea (at least given the current whitespace-related property values), it returns an incomplete layout status because it can't fit a LineArea in the remaining space. The result is that my outer Block returns incomplete, and so does the table cell, but what is actually composed is complete. So the next area composed is empty, except for the padding and borders. I haven't looked much into handling all these linefeed, whitespace properties (although it certainly would be on the menu for the New Layout...) and thought maybe you had. There is a method in FOText called willCreateArea() which is used by the widow/orphan code in Block. Then in LineArea there is more code to see what to do with spaces, which is more complicated. I'm not necessarily asking you to try to fix the bug I mentioned, but thought you might have something to say about it. Regards, Karen Lease Tore Engvig wrote: On Mon, 23 Jul 2001, Rainer Garus wrote: Is it possible to insert and commit the patch sended on 2001-06-28 to CVS? Had completely forgooten about your patch! Your reminder came just in time - I'm working on the LineArea class right now. I'm trying to add better support for spaces (there's about a dozen of different unicode spaces) and have problems with my non-breaking spaces causing an extra space at beginning of next line. I'll take a look at it. Tore Rainer Garus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Patch] bug 2243 - extra space at the beginning of next lineafter line feed
Hi Karen, I checked in my changes before I read your mail. The code I just checked in has a lot of changes regarding whitespace. I just looked at the bug and the the attached fo. I ran it through the new code and it renders different - the missing line is included now. I don't know if the bug appears as fixed because of the recent changes - but it might because the LineArea constructor now discards some pending InlineSpaces. I'll take a look at it. Tore On Tue, 24 Jul 2001, Karen Lease wrote: Hi Tore, While you're looking at whitespace in LineArea I thought you might be interested in a bug I noticed yesterday. Looking at a table bug report http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2740, I stumbled across a different problem. It turns out that the fo file has lots of trailing whitespace in most of its blocks (fairly common in many formatted .fo files). In fact, it has a structure that looks like this: table-cell -- block |-- whitespace |-- block -- text |-- whitespace The first whitespace gets eliminated in the Block class during the widow handling. Then the nested block gets laid out and fits completely in the remaining space. Then the outer block tries to layout its last child, which is only whitespace. But before discovering that it won't actually create a LineArea (at least given the current whitespace-related property values), it returns an incomplete layout status because it can't fit a LineArea in the remaining space. The result is that my outer Block returns incomplete, and so does the table cell, but what is actually composed is complete. So the next area composed is empty, except for the padding and borders. I haven't looked much into handling all these linefeed, whitespace properties (although it certainly would be on the menu for the New Layout...) and thought maybe you had. There is a method in FOText called willCreateArea() which is used by the widow/orphan code in Block. Then in LineArea there is more code to see what to do with spaces, which is more complicated. I'm not necessarily asking you to try to fix the bug I mentioned, but thought you might have something to say about it. Regards, Karen Lease Tore Engvig wrote: On Mon, 23 Jul 2001, Rainer Garus wrote: Is it possible to insert and commit the patch sended on 2001-06-28 to CVS? Had completely forgooten about your patch! Your reminder came just in time - I'm working on the LineArea class right now. I'm trying to add better support for spaces (there's about a dozen of different unicode spaces) and have problems with my non-breaking spaces causing an extra space at beginning of next line. I'll take a look at it. Tore Rainer Garus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Patch] bug 2243 - extra space at the beginning of next lineafter line feed
On Mon, 23 Jul 2001, Rainer Garus wrote: Is it possible to insert and commit the patch sended on 2001-06-28 to CVS? Had completely forgooten about your patch! Your reminder came just in time - I'm working on the LineArea class right now. I'm trying to add better support for spaces (there's about a dozen of different unicode spaces) and have problems with my non-breaking spaces causing an extra space at beginning of next line. I'll take a look at it. Tore Rainer Garus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
