https://issues.apache.org/bugzilla/show_bug.cgi?id=50471
Dominik Stadler changed:
What|Removed |Added
CC||dominik.stad...@gmx.at
https://issues.apache.org/bugzilla/show_bug.cgi?id=50471
Glenn Adams changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #6 from Glenn Ada
https://issues.apache.org/bugzilla/show_bug.cgi?id=50471
Andreas L. Delmelle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://issues.apache.org/bugzilla/show_bug.cgi?id=50471
--- Comment #4 from Andreas L. Delmelle 2011-01-07
07:31:03 EST ---
(In reply to comment #3)
> At least there should be some configuration available to the end user to tell
> FOP to use some default line break in such special cases it beco
https://issues.apache.org/bugzilla/show_bug.cgi?id=50471
--- Comment #3 from tvsud...@rediffmail.com 2011-01-06 23:36:48 EST ---
Andreas,
Thanks a lot for your response.
Actually we came across some special characters which are not intended to be
present in our database. We can figure out the r
https://issues.apache.org/bugzilla/show_bug.cgi?id=50471
--- Comment #2 from Chris Bowditch 2011-01-06
06:48:25 EST ---
Indeed you raise a very good point Andreas. Even if you make the code change, I
would expect # to appear in the output, because no font is likely to have a
glyph for a reserved
https://issues.apache.org/bugzilla/show_bug.cgi?id=50471
--- Comment #1 from Andreas L. Delmelle 2011-01-05
13:31:26 EST ---
Thanks for reporting, and apologies for the late reply...
At first glance, this seems like a minor oversight in the implementation of
Unicode linebreaking in FOP. This d
