https://issues.apache.org/bugzilla/show_bug.cgi?id=43474





--- Comment #19 from Chris Bowditch <[EMAIL PROTECTED]>  2008-11-28 01:07:46 
PST ---
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. 

As already indicated by Pascal there are some inconsistencies in the spec in
this area.

> > 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.

> Vincent

Thanks,

Chris


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to