DO NOT REPLY [Bug 43474] [PATCH] wrap-option=wrap doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 Glenn Adams gad...@apache.org changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #26 from Glenn Adams gad...@apache.org 2012-04-11 06:18:05 UTC --- change status from ASSIGNED to NEW for consistency -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43474] [PATCH] wrap-option=wrap doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 Glenn Adams gad...@apache.org changed: What|Removed |Added Priority|P3 |P2 --- Comment #25 from Glenn Adams gad...@apache.org 2012-04-11 03:22:33 UTC --- increase priority for bugs with a patch -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43474] [PATCH] wrap-option=wrap doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 --- Comment #24 from Glenn Adams gl...@skynav.com 2012-04-07 01:45:17 UTC --- resetting P2 open bugs to P3 pending further review -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43474] [PATCH] wrap-option=wrap doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 Glenn Adams gl...@skynav.com changed: What|Removed |Added Priority|P2 |P3 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43474] [PATCH] wrap-option=wrap doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 Sergey Vladimirov vlser...@gmail.com changed: What|Removed |Added CC||vlser...@gmail.com -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43474] [PATCH] wrap-option=wrap doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 --- Comment #23 from Andreas L. Delmelle adelme...@apache.org 2011-07-29 16:22:39 UTC --- (In reply to comment #22) Is there an updated patch for 1.0 version? I would like to use it, if possible. Unfortunately not, and I do not immediately have any time available to dedicate to porting it. Not that it would take _that_ much time, but still it's not a matter of minutes... That said, I do recall one peculiar effect that I think is not yet mentioned in this report: if you would have a mixture of words that do fit within the line with words that don't, then the wrapping effect would only be applied to the latter. That is, for the remainder you will get usual line-breaks, only those words that do not fit on the line in their entirety would ultimately get in-word breaks. That might lead to unexpected output, like: short short ver yveryverylong short short short where one might expect something like (true wrapping): short short ver yveryverylong s hort short shor t -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43474] [PATCH] wrap-option=wrap doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 --- Comment #22 from Sergey Vladimirov vlser...@gmail.com 2011-07-27 15:50:16 UTC --- Andreas, Is there an updated patch for 1.0 version? I would like to use it, if possible. Sergey -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43474] [PATCH] wrap-option=wrap doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 --- Comment #21 from stefan.hundham...@cassidian.com 2010-10-13 06:20:39 EDT --- The inconvenience of overflowing lines in table-cells when there is no break opportunity instead of generally breaking/wrapping a word to next line (as done by version 0.20.5 !) is the reason why we don't use version 0.95 and 1.0 Overwriting information in the next column is so critical in our eyes, that we will never use a tool doing so. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43474] [PATCH] wrap-option=wrap doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 --- Comment #17 from Vincent Hennebert [EMAIL PROTECTED] 2008-11-27 03:33:03 PST --- (In reply to comment #16) (In reply to comment #15) I'm sorry to chime in so late but I don't think there is anything to do on FOP's side WRT this issue. On the one hand, I agree. I have mentioned this already in the past: wrap-option=wrap does not include an /obligation/ to perform line-wrapping. If there is no opportunity to break inside the word then there's nothing FOP can do. Wrong. At least, slightly unfortunate choice of words: FOP /can/ definitely do /something/ in this case. The wrap-option property is meant to trigger the line-breaking mechanism in its usual accepted meaning; that is, break between words or at hyphenation points inside them, not at every letter if available space is abnormally low, or the word abnormally big. At least, that's my understanding of this property. IIC, there's a subtle difference between line-WRAPPING and line-BREAKING. Line-wrapping being the more 'blind' of the two, if you will (simply wrap to fit the text into the available space). The Recommendation remains vague in this respect (and purposely so, I think). I don't think so. Section 4.7.2, “Line-building”, states that “The partitioning [must occur] at legal line-breaks. [...] the rules of the language, script and hyphenation constraints in effect must permit a line-break between [two areas].” http://www.w3.org/TR/xsl11/#area-linebuild It /might/ be acceptable to relax the line-breaking algorithm somehow when the 'script' property is set to 'none', but frankly I'm not too keen on implementing a special treatment just to cope with pathological cases. The code is already complicated enough. It does not prescribe /how/ the text should be wrapped or broken. We have decided to follow Unicode, but ultimately, we always have the last word. That is: if we choose to provide an additional fallback mechanism, there is no relevant specification that makes this wrong. In my opinion, this issue must be handled upstream. That is, zero-width space characters (U+200B) must be introduced at applicable places inside the word to provide FOP with more break opportunities. A legitimate option, but not always as easily done as it said. To get the effect of real dynamic content-wrapping (fit as many characters on the line as you can), you would force the user to insert a ZWSP in between every two characters (either that or they should make a choice of every so-many characters). Exactly. And I bet it's less complicated to implement some XSLT function or pre-processing step to do that than a dedicated extension in FOP's layout engine. But I don't think this is FOP's responsibility to do that. See also the following FAQ entry: http://xmlgraphics.apache.org/fop/faq.html#cells-overflow Maybe not, but it would mean a big relief for many users, I think, if FOP would take this responsibility, even if it is not mandated... Yes, but if we reason like this FOP would soon become like those Swiss knives with ridiculous numbers of blades ;-) (Note that I have nothing against Swiss knives, I've been owning one myself for years and it serves me very well! But it has only 6 functions.) More seriously, you could take it the other way around, and find users who wouldn't be happy at all to see FOP suddenly break their texts at arbitrary places, and would rather be warned when such situations are occuring, so that they can re-work their contents. Vincent -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43474] [PATCH] wrap-option=wrap doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 --- Comment #18 from Pascal Sancho [EMAIL PROTECTED] 2008-11-27 05:06:36 PST --- (In reply to comment #17) wrap-option is cited 3 times in REC 1.1: [1] Section 1.2.1 Paging and Scrolling [2] Section 4.7.2 Line-building [3] Section 7.16.13 wrap-option IMHO, there is inconsistency in recommendation, especially between [2] and [3]: in [3], when wrap-option=wrap, REC says line-breaking will occur if the line overflows the available block width but in [2], there is no tool to do what is required in [3], as Vincent said. So, I wonder whether FOP should not enforce a break if there is no break opportunity other than between 2 normal chars, regarding the wrap-option. [1] http://www.w3.org/TR/xsl11/#d0e297 [2] http://www.w3.org/TR/xsl11/#area-linebuild [3] http://www.w3.org/TR/xsl11/#wrap-option Pascal -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43474] [PATCH] wrap-option=wrap doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 --- Comment #15 from Vincent Hennebert [EMAIL PROTECTED] 2008-11-26 03:59:32 PST --- Hi, I'm sorry to chime in so late but I don't think there is anything to do on FOP's side WRT this issue. If there is no opportunity to break inside the word then there's nothing FOP can do. The wrap-option property is meant to trigger the line-breaking mechanism in its usual accepted meaning; that is, break between words or at hyphenation points inside them, not at every letter if available space is abnormally low, or the word abnormally big. At least, that's my understanding of this property. In my opinion, this issue must be handled upstream. That is, zero-width space characters (U+200B) must be introduced at applicable places inside the word to provide FOP with more break opportunities. But I don't think this is FOP's responsibility to do that. See also the following FAQ entry: http://xmlgraphics.apache.org/fop/faq.html#cells-overflow Vincent (In reply to comment #14) (In reply to comment #11) I created a patch working with the latest trunk version. It's similar to the last patch. But there were some further problems which are fixed, list-item-labels were always wrapped, and the algorithm for choosing the correct break position was not correct inside tables. I think this functionality is very important for a lot of users as there is even a faq entry. Good to see this being picked up. I'm in the process of reviewing the patch, and already have some questions/considerations: I'm not sure I like the additional reference to ListItemLabel in TextLayoutManager. The TextLM should deal with text (FOText), and if necessary, the ancestor ListItemContentLM should pass the necessary info (a flag in the LayoutContext?) down to prevent the label from being broken. Right now, a dev would have to look at the TextLM to find out why a list-item-label is never broken...? I'd rather see an accompanying change to the list-related LMs to account for this. I'll see if I can come up with a polished alternative, to show what I mean. As to the cause for the fact that the label is always broken: this is probably because the area gets its inline-progression-dimension from the content, so when the element-list is first constructed, the reference-ipd (line-width) will still be zero... I agree that not breaking would be the preferred behavior. If a user really needs this effect, he/she can always resort to a two-column table. The changes to LineLM: Are they necessary due to the changes to TextLM, or is that a separate issue? Just asking, since the javadoc for the first added private method seems to indicate that the original expression could return a wrong result regardless of the value of wrap-option (?) The same style issues as Chris mentioned in #42374 put aside, your patch has given me some ideas, which I'll start trying out real soon. Thanks for your input so far! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43474] [PATCH] wrap-option=wrap doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 --- Comment #16 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-11-26 11:30:42 PST --- (In reply to comment #15) I'm sorry to chime in so late but I don't think there is anything to do on FOP's side WRT this issue. On the one hand, I agree. I have mentioned this already in the past: wrap-option=wrap does not include an /obligation/ to perform line-wrapping. If there is no opportunity to break inside the word then there's nothing FOP can do. Wrong. At least, slightly unfortunate choice of words: FOP /can/ definitely do /something/ in this case. The wrap-option property is meant to trigger the line-breaking mechanism in its usual accepted meaning; that is, break between words or at hyphenation points inside them, not at every letter if available space is abnormally low, or the word abnormally big. At least, that's my understanding of this property. IIC, there's a subtle difference between line-WRAPPING and line-BREAKING. Line-wrapping being the more 'blind' of the two, if you will (simply wrap to fit the text into the available space). The Recommendation remains vague in this respect (and purposely so, I think). It does not prescribe /how/ the text should be wrapped or broken. We have decided to follow Unicode, but ultimately, we always have the last word. That is: if we choose to provide an additional fallback mechanism, there is no relevant specification that makes this wrong. In my opinion, this issue must be handled upstream. That is, zero-width space characters (U+200B) must be introduced at applicable places inside the word to provide FOP with more break opportunities. A legitimate option, but not always as easily done as it said. To get the effect of real dynamic content-wrapping (fit as many characters on the line as you can), you would force the user to insert a ZWSP in between every two characters (either that or they should make a choice of every so-many characters). But I don't think this is FOP's responsibility to do that. See also the following FAQ entry: http://xmlgraphics.apache.org/fop/faq.html#cells-overflow Maybe not, but it would mean a big relief for many users, I think, if FOP would take this responsibility, even if it is not mandated... -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43474] [PATCH] wrap-option=wrap doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 Chris Bowditch [EMAIL PROTECTED] changed: What|Removed |Added Summary|wrap-option=wrap doesn't |[PATCH] wrap-option=wrap |work|doesn't work -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43474] [PATCH] wrap-option=wrap doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 --- Comment #14 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-11-25 10:56:12 PST --- (In reply to comment #11) I created a patch working with the latest trunk version. It's similar to the last patch. But there were some further problems which are fixed, list-item-labels were always wrapped, and the algorithm for choosing the correct break position was not correct inside tables. I think this functionality is very important for a lot of users as there is even a faq entry. Good to see this being picked up. I'm in the process of reviewing the patch, and already have some questions/considerations: I'm not sure I like the additional reference to ListItemLabel in TextLayoutManager. The TextLM should deal with text (FOText), and if necessary, the ancestor ListItemContentLM should pass the necessary info (a flag in the LayoutContext?) down to prevent the label from being broken. Right now, a dev would have to look at the TextLM to find out why a list-item-label is never broken...? I'd rather see an accompanying change to the list-related LMs to account for this. I'll see if I can come up with a polished alternative, to show what I mean. As to the cause for the fact that the label is always broken: this is probably because the area gets its inline-progression-dimension from the content, so when the element-list is first constructed, the reference-ipd (line-width) will still be zero... I agree that not breaking would be the preferred behavior. If a user really needs this effect, he/she can always resort to a two-column table. The changes to LineLM: Are they necessary due to the changes to TextLM, or is that a separate issue? Just asking, since the javadoc for the first added private method seems to indicate that the original expression could return a wrong result regardless of the value of wrap-option (?) The same style issues as Chris mentioned in #42374 put aside, your patch has given me some ideas, which I'll start trying out real soon. Thanks for your input so far! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
