Bug 43166 - unclosed border on nested inlines
Summary: unclosed border on nested inlines
Status: CLOSED FIXED
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: page-master/layout (show other bugs)
Version: trunk
Hardware: PC Windows 2000
: P2 normal
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-20 02:32 UTC by Guillaume Levrero
Modified: 2012-04-01 06:18 UTC (History)
1 user (show)



Attachments
FO to reproduce bug (709 bytes, text/plain)
2007-08-20 02:33 UTC, Guillaume Levrero
Details
Patch (1.39 KB, patch)
2010-12-19 19:04 UTC, Matthias Reischenbacher
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Guillaume Levrero 2007-08-20 02:32:28 UTC
On nested inlines, if the outer inline has a border and the inner inline hasn't.
The right border is not rendered.
Comment 1 Guillaume Levrero 2007-08-20 02:33:14 UTC
Created attachment 20678 [details]
FO to reproduce bug
Comment 2 Matthias Reischenbacher 2010-12-19 19:04:28 UTC
Created attachment 26425 [details]
Patch

The border isn't rendered because InlineLevelLayoutManger fails to detect the last knuth element due to an incorrect value of the position counter (lastGeneratedPosition in AbstractLayoutManager). The counter is incremented when adding letter spacing and actually no new knuth element is added to the sequence because an existing one is just replaced. Decreasing the counter before letter spacing is applied fixes this issue.
Comment 3 Simon Pepping 2010-12-22 13:39:40 UTC
The patch works of course, but it looks a bit like magic. I would like to dig deeper into this. I am surprised that the actual value of the index makes such a difference. It would be helpful if you would indicate:

1. where in the code the border is added or not added to the result page, depending on the value of the index;

2. where in the code the knuth element is replaced instead of being added.
Comment 4 Matthias Reischenbacher 2010-12-28 15:16:28 UTC
(In reply to comment #3)
> The patch works of course, but it looks a bit like magic. I would like to dig
> deeper into this. I am surprised that the actual value of the index makes such
> a difference. It would be helpful if you would indicate:

You're right, the patch only does magic, but doesn't really fix the problem. Debugging again I discovered, that the letter space is added to an existing sequence and then the elements of a new sequence are also added to the existing sequence. See: InlineKnuthSequence.appendSequence(). Since notifyPos() has already been called for the positions of the new sequence (see InlineLayoutManager.getNextKnuthElements() --> sequence.wrapPositions()), the letter space has a higher index than the positions of the new sequence, although it is added before it. This causes the positions of the final sequence to be something like that:
-1 (border)
0
2 (letter spacing)
1
-1 (border)

When hyphenation is used and hyphenation opportunities are found this is no problem because all positions get a new index when InlineStackingLayoutManager.applyChanges() is executed.

> 1. where in the code the border is added or not added to the result page,
> depending on the value of the index;

This happens inside:
InlineLayoutManager.addAreas()
--> setTraits(areaCreated, lastPos == null || !isLast(lastPos));

> 2. where in the code the knuth element is replaced instead of being added.

That was just no sense of my part. The letter space is added as a new knuth element and nothing is replaced.
Comment 5 Simon Pepping 2011-01-07 10:48:08 UTC
Works OK now, probably due to the improvements in revision 1052561.
Comment 6 Glenn Adams 2012-04-01 06:18:00 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