--- Comment #15 from Vincent Hennebert <[EMAIL PROTECTED]> 2008-11-26 03:59:32
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. If there is no opportunity to break inside the word
then there's nothing FOP can do. 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.
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. But I don't think this is FOP's
responsibility to do that. See also the following FAQ entry:
(In reply to comment #14)
> (In reply to comment #11)
> > I created a patch working with the latest trunk version. It's similar to the
> > last patch. But there were some further problems which are fixed,
> > list-item-labels were always wrapped, and the algorithm for choosing the
> > correct break position was not correct inside tables. I think this
> > functionality is very important for a lot of users as there is even a faq
> > entry.
> Good to see this being picked up.
> I'm in the process of reviewing the patch, and already have some
> I'm not sure I like the additional reference to ListItemLabel in
> TextLayoutManager. The TextLM should deal with text (FOText), and if
> the ancestor ListItemContentLM should pass the necessary info (a flag in the
> LayoutContext?) down to prevent the label from being broken.
> Right now, a dev would have to look at the TextLM to find out why a
> list-item-label is never broken...? I'd rather see an accompanying change to
> the list-related LMs to account for this. I'll see if I can come up with a
> polished alternative, to show what I mean.
> As to the cause for the fact that the label is always broken: this is probably
> because the area gets its inline-progression-dimension from the content, so
> when the element-list is first constructed, the reference-ipd (line-width)
> still be zero... I agree that not breaking would be the preferred behavior. If
> a user really needs this effect, he/she can always resort to a two-column
> The changes to LineLM: Are they necessary due to the changes to TextLM, or is
> that a separate issue? Just asking, since the javadoc for the first added
> private method seems to indicate that the original expression could return a
> wrong result regardless of the value of wrap-option (?)
> The same style issues as Chris mentioned in #42374 put aside, your patch has
> given me some ideas, which I'll start trying out real soon.
> Thanks for your input so far!
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.