> /
>> Unfortunately, the original reporter did not take the time to reduce
>> the example to a 'minimal' one.
>> ...
>> which makes it more difficult to pinpoint the cause.
>>
>
> I am willing to reduce it a bit, but all next week I won't have an access to
> my PC.
No worries, I already got th
On 2015-07-24 Andreas L. Delmelle wrote:
>
> https://issues.apache.org/jira/secure/attachment/12558413/FOP_TOC_Bug_T
> est.fo
>
> I tried that one indeed, and noticed it still has misalignments, albeit
> very minor.
Just a note, comparing both FOP-1444-original.pdf and
FOP-1444-original_after.pd
On 2015-07-24 Andreas L. Delmelle wrote:
> I tried that one indeed, and noticed it still has misalignments, albeit
> very minor. Overall, the alignment does look a bit better than before
> the patch and quite a lot better than the originally attached PDF from
> 8 years ago, but still not entirely
> On 24 Jul 2015, at 15:00, Andreas L. Delmelle
> wrote:
>
>> On 24 Jul 2015, at 12:08, Jan Tosovsky wrote:
>>
>> Are you referring to Pascal comment from 16/Oct/13? In this case I'd rather
>> create a dedicated issue (if it is still relevant) as the original text and
>> majority of comment
> On 24 Jul 2015, at 12:08, Jan Tosovsky wrote:
>
> On 2015-07-24 Andreas L. Delmelle wrote:
>> On the other hand, note that it does not (entirely) solve the original
>> issue reported in FOP-1444, which seems to be more related to using
>> fo:page-number-citation.
>
> Are you referring to Pasc
Hi Andreas,
On 2015-07-24 Andreas L. Delmelle wrote:
> > On 2015-07-23 Jan Tosovsky wrote:
> >
> > Do you expect this difference should be further eliminated or your
> > patch is ready for incorporating into trunk?
>
> ...
> On the other hand, note that it does not (entirely) solve the original
>
Hi Jan
> On 23 Jul 2015, at 21:47, Jan Tosovsky wrote:
>
>
> Do you expect this difference should be further eliminated or your patch is
> ready for incorporating into trunk?
At first glance, it looks like the change can be committed to trunk with little
risk. That is: it does not break any
Hi Andreas,
wow, I am impressed by your detective work...
On 2015-07-23 Andreas L. Delmelle wrote:
> > On 2015-07-22 Jan Tosovsky wrote:
> >
> > I've removed whitespace between all inlines (spaces seem to influence
> > this behaviour significantly) and I can confirm that 'keep*' property
> > ha
Hi Jan
> On 22 Jul 2015, at 23:32, Jan Tosovsky wrote:
>
>
> I've removed whitespace between all inlines (spaces seem to influence this
> behaviour significantly) and I can confirm that 'keep*' property has some
> influence here.
Indeed, good catch! I also looked a bit closer on my end, and it
firm that 'keep*' property has some
influence here.
Lorem ipsum7
Lorem
ipsum7
While I initialy expected zero and non-zero ipdAdjust, I am getting rather
two non-zero values which slightly differ (1398 vs 1393).
W
Hi Jan
I have an update on this.
> On 22 Jul 2015, at 13:55, Andreas L. Delmelle
> wrote:
>
>
> 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 c
r.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?
>
tead 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, I did notice something that does in
58 + 15290) one gets 41102. And this difference matches that
shift of the page number.
What does that IPDAdjust represent?
Thanks, Jan
14 matches
Mail list logo
