|
»
»
»
« Return to Thread: Hacking a temporary solution for Changing IPD
Re: Hacking a temporary solution for Changing IPD
by cbowditch
::
Rate this Message:
Vincent Hennebert wrote:
> Hi All,
Hi Vincent,
>
> While I am making rather good progress on my prototype implementation of
> a new layout approach, I am not likely to get any practical results
> before some time (a year or more). Meanwhile, users keep bumping into
> this Changing IPD issue, which is becoming more and more problematic.
>
> It would be good if we had some partial, temporary solution with which
> users could live until the new approach has been implemented. In many
> cases, the ‘Changing IPD’ problem boils down to the first page of the
> sequence having some sort of side region encroaching upon the main
> content, and all the following pages having the same width. And the
> content is usually made of just plain text (fo:block elements).
I have also seen use cases along those lines.
>
> I spent some time looking at the current code and it seems to me that
> a hack could be implemented without too many difficulties. It basically
> consists in 2 steps:
> 1. in the Knuth breaking algorithm, when creating a new active node,
> look whether the IPD for the following page is the same or not. If
> not, deactivate the node. Once we run out of active nodes, select the
> best of those deactivated nodes and treat it as if it were the
> regular final node. Add areas for content up to that node.
>
> 2. re-create Knuth elements, starting from the index corresponding to
> that node. Re-launch the breaking algorithm, starting from there.
> Then back to step 1, until the end of the document is reached.
>
> Step 1 should be doable without turning everything upside down. Step
> 2 implies to change the signature of the
> LayoutManager.getNextKnuthElements method, adding a parameter that
> corresponds to the index from where to start the generation of Knuth
> elements. We could largely ignore it, except in BlockLayoutManager where
> we would re-launch the line-breaking algorithm, taking the new IPD into
> account.
I can't offer much technical help with the above as I'm not familar with
those areas of the code.
>
> Obviously this is a limited approach. There is likely to be
> a (potentially huge) waste of CPU cycles due to the re-creation of Knuth
> elements. There may be side effects that I’ve missed so far. But I think
> it’s worth giving it a try.
Will the increase in CPU cycles only occur if there is a change in IPD,
or will this affect performance for existing users with the same width
on every page?
>
> What I’m planning to do is create a branch in which I would experiment
> that idea. If it turns out to be feasible then we could merge it back to
> Trunk, advertise the ‘fix’ and document its limitations. And hopefully
> that will relieve some pressure on the implementation of the more
> complete new approach.
Thanks,
Chris
> Hi All,
Hi Vincent,
>
> While I am making rather good progress on my prototype implementation of
> a new layout approach, I am not likely to get any practical results
> before some time (a year or more). Meanwhile, users keep bumping into
> this Changing IPD issue, which is becoming more and more problematic.
>
> It would be good if we had some partial, temporary solution with which
> users could live until the new approach has been implemented. In many
> cases, the ‘Changing IPD’ problem boils down to the first page of the
> sequence having some sort of side region encroaching upon the main
> content, and all the following pages having the same width. And the
> content is usually made of just plain text (fo:block elements).
I have also seen use cases along those lines.
>
> I spent some time looking at the current code and it seems to me that
> a hack could be implemented without too many difficulties. It basically
> consists in 2 steps:
> 1. in the Knuth breaking algorithm, when creating a new active node,
> look whether the IPD for the following page is the same or not. If
> not, deactivate the node. Once we run out of active nodes, select the
> best of those deactivated nodes and treat it as if it were the
> regular final node. Add areas for content up to that node.
>
> 2. re-create Knuth elements, starting from the index corresponding to
> that node. Re-launch the breaking algorithm, starting from there.
> Then back to step 1, until the end of the document is reached.
>
> Step 1 should be doable without turning everything upside down. Step
> 2 implies to change the signature of the
> LayoutManager.getNextKnuthElements method, adding a parameter that
> corresponds to the index from where to start the generation of Knuth
> elements. We could largely ignore it, except in BlockLayoutManager where
> we would re-launch the line-breaking algorithm, taking the new IPD into
> account.
I can't offer much technical help with the above as I'm not familar with
those areas of the code.
>
> Obviously this is a limited approach. There is likely to be
> a (potentially huge) waste of CPU cycles due to the re-creation of Knuth
> elements. There may be side effects that I’ve missed so far. But I think
> it’s worth giving it a try.
Will the increase in CPU cycles only occur if there is a change in IPD,
or will this affect performance for existing users with the same width
on every page?
>
> What I’m planning to do is create a branch in which I would experiment
> that idea. If it turns out to be feasible then we could merge it back to
> Trunk, advertise the ‘fix’ and document its limitations. And hopefully
> that will relieve some pressure on the implementation of the more
> complete new approach.
Thanks,
Chris
« Return to Thread: Hacking a temporary solution for Changing IPD
| Free embeddable forum powered by Nabble | Forum Help |
