Bug 49848 - keep-together.within-line="always" does not work with nested fo:inline
Summary: keep-together.within-line="always" does not work with nested fo:inline
Status: CLOSED FIXED
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: page-master/layout (show other bugs)
Version: 0.95
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-31 02:35 UTC by Alexey Neyman
Modified: 2012-04-01 06:18 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Neyman 2010-08-31 02:35:46 UTC
As per suggestion on fop-users@, entering an issue:

I am trying to prevent a line from breaking, so I wrapped it inside a 
<fo:inline keep-together.within-line="always">...</fo:inline>. This works as 
long as the line is a plain text, but does not work if there is a nested 
fo:inline. In that case, the line breaks at the nested fo:inline.

Here is a FO snippet:

===========================
<fo:inline keep-together.within-line="always">very long and nasty 
<fo:inline/>line that should not probably wrap unless somebody is using a 
nested fo inline <fo:inline/> which allows this line to wrapping 
around<fo:inline/> even though it should not</fo:inline>
===========================

I am using FOP 0.95, packages from Ubuntu 10.04.
Comment 1 Andreas L. Delmelle 2011-01-07 07:38:42 UTC
Studying this issue closer, it seems to originate in TextLM, line 708:
...
        } else if (inWhitespace) {
            processWhitespace(alignment, sequence, true);
...

The literal 'true' means that when finishing the TextLM element list, it is assumed that there is always supposed to be a break opportunity at the end, while in reality, this obviously depends...

Using a literal 'true' as parameter value, we get a sequence of Glue-Penalty-Glue for the space before the nested inline. This produces a break opportunity that is used by the LineBreakingAlgorithm.

Using '!keepTogether' instead, produces only an auxiliary box in this case and seems to resolve it.
Comment 2 Andreas L. Delmelle 2011-01-09 09:43:16 UTC
Fixed in Trunk. See: http://svn.apache.org/viewvc?rev=1056945&view=rev
Comment 3 Glenn Adams 2012-04-01 06:18:20 UTC
batch transition to closed; if someone wishes to restore one of these to resolved in order to perform a verification step, then feel free to do so