--- Comment #20 from Vincent Hennebert <[EMAIL PROTECTED]> 2008-11-28 02:37:30
(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
> 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
> > > 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
> 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.
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.