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.
