If a <fo:block> node in the XSL:FO source given to FOP has the hyphenate="true" attribute set, enabling hyphenation, and the contents of the block have lots of consecutive digits stretching beyond the block boundary, like so: | <-- boundary The phone number is 12345678901234567890. then FOP splits the consecutive digits at the boundary, rendering the text like so: | <-- boundary The phone number is 1234567890123 4567890. I would prefer it to treat the entire digit sequence as a single, non-hyphenatable word, causing it to render as follows: | <-- boundary The phone number is 12345678901234567890. However, I couldn't find out any way to configure FOP to do this, because it uses the same hyphenation pattern format as TeX, and apparently TeX only takes letters, not other symbols, into account when parsing the hyphenation rules. Is there some kind of way I could stop FOP from splitting consecutive digits onto separate rows?
The correct way to stop a piece of text being split across line/page/column bounaries in XSL-Fo is to use keep-* properties. e.g. <fo:inline keep-together="always">12345678901234567890</fo:inline> However, keep-* properties are not implemented in 0.20.5. They have been implemented in the current development version. 0.20.5 is about to be superceeded by a release of the development code and since work has stopped on the maintenance code, this bug won't be fixed in 0.20.5 and I'm closing this bug report.
The suggested fix wouldn't work in my case. To achieve what I want to do with the suggested fix, I'd have to write the <fo:block> as: <fo:block hyphenation="true"><fo:inline>The phone number is </fo:inline><fo:inline keep-together="always">12345678901234567890</fo:inline><fo:inline>.</fo:inline></fo:block> However, the text contents of the <fo:block> are dynamically generated and thus I can't decide in advance where the <fo:inline> nodes should go. I am reopening this bug. If the bug is invalid because of the wrong version, please reclose the bug and tell me how to report it with the corret version.
I can't prove it but I'd say that FOP 0.20.5 illegally splits the long number. A number is not subject to hyphenation, is it? Anyway, FOP Trunk currently doesn't split the number but keep-together.within-line doesn't work, either. So, Joona would actually be fine with FOP Trunk except that there is no warning message, yet, when a word is rendered beyond the content rectangle (i.e. overflows the box). Other FO implementations compress the word to fit it into the content rectangle but that's probably a bad idea since it results in badly looking output. IMO this bug can be closed again, but only because Joona's problem shouldn't happen in FOP Trunk and it won't be fixed in 0.20.5. I don't have a work-around for 0.20.5, either, except to try to shut off hyphenation. Sorry. The missing keep-together.within-line feature is a different story and IMO not related to Joona's problem.
please provide (1) an input FO test file, (2) an output PDF file (if any), (3) console output as file (if any), and (4) FOP version being tested