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