> On 22 Jul 2015, at 11:11, Andreas L. Delmelle <[email protected]>
> wrote:
>
> Hi Jan
>
>> On 22 Jul 2015, at 00:36, Jan Tosovsky <[email protected]> wrote:
>>
>> <snip />
>> But 'Item 2.1' is wrapped by BasicLinkLM and during its processing in
>> TextLayoutManager.addMappingAreas() a special treatment is performed as
>> context.getIPDAdjust() returns non zero value. So instead of width 39743
>> (21395 + 3058 + 15290) one gets 41102. And this difference matches that
>> shift of the page number.
>>
>> What does that IPDAdjust represent?
>
> While I cannot immediately say what the "ipd adjustment" is supposed to
> represent, ...
Looking closer, it suddenly dawned on me that this represents the so-called
"adjustment ratio" of a given break possibility. This is one of the factors --
effect not to be underestimated -- that determines the feasibility (demerits)
of actually breaking at that position.
If I interpret correctly from the code, it is only supposed to count in case
(at least) one of the following is true:
1° text-align is set to "justify"
2° the "difference" associated with the break possibility, which is
essentially the amount of space
left within the line if a break occurs at the given position, is both
negative and smaller than the available
"shrink" -- i.e. the content would overflow the line if nothing special
happens, but some of the glues can be
shrunk to make the content fit anyway
> I did notice something that does influence the result: the extra layer of
> fo:inlines, that only seem to be there to carry the keep-together.within-line
> property.
I would focus the efforts on trying to get a better view on the difference in
processing between the two situations: with and without the extra fo:inline.
Likely, the extra level of nesting causes some additional, auxiliary elements
to be added to the content list, which are taken into account while they should
not be.
KR
Andreas
