The following code: <?xml version="1.0" encoding="iso-8859-1"?> <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"> <fo:layout-master-set> <fo:simple-page-master master-name="my-page"> <fo:region-body margin="1in"/> </fo:simple-page-master> </fo:layout-master-set> <fo:page-sequence hyphenate="true" language="en" master-reference="my-page"> <fo:flow flow-name="xsl-region-body"> <fo:block linefeed-treatment="preserve">First line Second line</fo:block> </fo:flow> </fo:page-sequence> </fo:root> results in an output of: FirstlineSecondline FirstlineSecondline Without the language="en" attribute the output is (as expected) First line Second line This seems to be independent of the chosen output format.
(In reply to comment #0) > > Without the language="en" attribute the output is (as expected) > First line > Second line > > This seems to be independent of the chosen output format. Apologies for the late reply... The real issue seems to be the combination of hyphenation with preserved linefeeds, which is a registered, as yet unsolved bug. See Bug #38264. I last had a look at that one over two years ago, but I think the basic story as sketched in that report still holds: three paragraphs are generated by the line-breaking algorithm (two genuine and an empty one), which are post-processed to apply hyphenation, and this post-processing implicitly assumes that a TextLM will always generate one and only one paragraph. When you remove the language attribute, hyphenation is not triggered, so the issue does not occur. If you really get hyphenation points and have more preserved linefeeds, the effects are reinforced. In extreme cases, you hardly recognize the original text. So, I got that itch again, and dove into the code... I already solved this particular manifestation in my local sandbox, simply by doing something I initially expected would already help: invert the principal loop in LineLM.createLineBreaks(). Unless I am missing something, there really seems to be no benefit in that loop going backward, unless of course one considers confusing people trying to follow the flow to be beneficial... Errm... :-> This solves the issue, but only in this very confined testcase. The hyphenation 'updates' are still applied twice, but there really is no difference (= none of the calculated hyphenation points are actually used, since both pieces of text fit well within one line) I am marking this one as duplicate. Please post any follow-up at #38264 *** This bug has been marked as a duplicate of bug 38264 ***
(In reply to comment #1) > I already solved this particular manifestation in my local sandbox, simply by > doing something I initially expected would already help: invert the principal > loop in LineLM.createLineBreaks(). Just adding this here for the sake of completeness: turns out that inverting that loop had nothing to do with it. Current FOP Trunk does not exhibit the described behavior, even with the loop inverted. The 'fix' is actually due to a change made last year to cater for changing IPD between pages. There was a 'hyphenationPerformed' member added to LineLayoutManager which effectively masks the problem in this case. This makes sure that findHyphenationPoints is called only once per LineLM. In case of preserved linefeeds, this results in only the first paragraph being hyphenated.
batch transition to closed remaining pre-FOP1.0 resolved bugs