https://issues.apache.org/bugzilla/show_bug.cgi?id=43474
--- Comment #20 from Vincent Hennebert <[EMAIL PROTECTED]> 2008-11-28 02:37:30 PST --- Hi Chris, (In reply to comment #19) > Hi Vincent, > > (In reply to comment #17) > > (In reply to comment #16) > > > (In reply to comment #15) > > > 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. > > Agreed that the code is complex, but I don't believe we are dealing with > extreme or pathological cases here. Most users run into the problem of content > overflowing a table cell at some point and this is shown by the number of > questions on the subject that occuir on fop-user. Far too many for my liking. Well, in most cases this was because they were using the keep-together shorthand, that from version 0.95 on started to be applied to lines as well. Usually they were happy with the result once they switched to keep-together.within-column. > As already indicated by Pascal there are some inconsistencies in the spec in > this area. I guess the best way to have a definitive answer is to ask for clarification on xsl-editors@ > > > 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. > > Well I agree that FOP shouldn't agree to a code change for every possible > use-case, but we should try to adjust the code to assist the most common use > cases. I do believe that text with few break possibilities in narrow table > columns is a common use case. > > The other thing to bear in mind is that no one is saying this feature has to > be > implemented right now, but I don't think it should be dismissed either. Sure ;-) I guess something could be done when the 'script' property is implemented, but I keep thinking that the issue is better solved upstream. > Thanks, > > Chris 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.
